From: Jeff D. <jd...@ka...> - 2001-10-05 19:27:04
|
do...@de... said: > Wouldn't it be better to honor $TMP or $TEMP? Yup. It sure would. Send me a patch and I'll put it in. Jeff |
From: Jeff D. <jd...@ka...> - 2001-10-06 01:35:37
|
ad...@do... said: > I just noticed that the unlinked file descriptor for temp files is > given the perms of 777. I consider that a security hole. > How about I make this a command line option as well? How about just fixing it so it's right? I don't see any value in letting it be tweaked from the command line. In any case, what's the problem with the permissions? The file has been unlinked already, so the only outside access to it is through /proc. And for that matter, I don't see why it needs to be fchmod-ed in the first place. Jeff |
From: Jeff D. <jd...@ka...> - 2001-10-06 01:37:01
|
ad...@do... said: > I have __uml_init and __uml_initcall() working, with functions defined > as such being automatically called at boot time. These are different > from normal __initcalls(), in that they are for uml stuff. What's wrong with the normal __initcalls()? They work just fine. Jeff |
From: Adam H. <ad...@do...> - 2001-10-06 02:54:20
|
On Fri, 5 Oct 2001, Jeff Dike wrote: > ad...@do... said: > > I have __uml_init and __uml_initcall() working, with functions defined > > as such being automatically called at boot time. These are different > > from normal __initcalls(), in that they are for uml stuff. > > What's wrong with the normal __initcalls()? They work just fine. There are 2 stages to uml init. User-space init, and kernel-space init. I'm doing the former. |
From: Jeff D. <jd...@ka...> - 2001-10-06 03:36:41
|
ad...@do... said: > There are 2 stages to uml init. User-space init, and kernel-space > init. I'm doing the former. Oh, OK. I was thinking you were doing something different. > Well, it works. Now, I'm integrating the help text properly. > __uml_setup("root=",uml_root_setup, That sounds reasonable too. > Additionally, since all this data is static, and located in one place, > it is possible to 'reuse' the memory block. Actually, the right thing to do there is the same thing native kernels do, which is to free that memory back to kmalloc so the rest of the system can use it. This would require locating the UML binary in its own physical memory, but that can be done cleanly now that the address space reorg has happened. Jeff |
From: Adam H. <ad...@do...> - 2001-10-06 03:42:32
|
On Fri, 5 Oct 2001, Jeff Dike wrote: > Actually, the right thing to do there is the same thing native kernels do, > which is to free that memory back to kmalloc so the rest of the system can > use it. This would require locating the UML binary in its own physical > memory, but that can be done cleanly now that the address space reorg has > happened. When I last looked at uml's vm(over 6 months ago), the kernel binary was outside the memory space of the emulated user-space. In normal kernels, the kernel's memory and user-space share the same physical space, so reusing the kernel memory is straight forward. Is this not the case? |
From: Jeff D. <jd...@ka...> - 2001-10-06 15:57:01
|
ad...@do... said: > When I last looked at uml's vm(over 6 months ago), the kernel binary > was outside the memory space of the emulated user-space. That's still the case, but now, physical memory is adjacent to the binary. So, putting UML in its own memory is now a matter of setting physmem to be the start of the binary making sure that the memory occupied by the binary isn't released to kmalloc copying the binary into the physical memory file rather than its own file > so reusing the kernel memory is straight forward. Once that's done, it will be possible to reuse __init memory in exactly the same way native kernels do. Jeff |
From: Adam H. <ad...@do...> - 2001-10-05 23:40:14
|
On Fri, 5 Oct 2001, Jeff Dike wrote: > do...@de... said: > > Wouldn't it be better to honor $TMP or $TEMP? > > Yup. It sure would. Send me a patch and I'll put it in. Well, I have it working. However, it depends on another patch that I am still in the process of creating, one that will simply all sorts of code paths. I have __uml_init and __uml_initcall() working, with functions defined as such being automatically called at boot time. These are different from normal __initcalls(), in that they are for uml stuff. I'll be doing the command line stuff the same way, before I send the patch off. |
From: Adam H. <ad...@do...> - 2001-10-06 03:09:39
|
On Fri, 5 Oct 2001, Adam Heath wrote: > On Fri, 5 Oct 2001, Jeff Dike wrote: > > > do...@de... said: > > > Wouldn't it be better to honor $TMP or $TEMP? > > > > Yup. It sure would. Send me a patch and I'll put it in. > > Well, I have it working. However, it depends on another patch that I am still > in the process of creating, one that will simply all sorts of code paths. > > I have __uml_init and __uml_initcall() working, with functions defined as such > being automatically called at boot time. These are different from normal > __initcalls(), in that they are for uml stuff. > > I'll be doing the command line stuff the same way, before I send the patch > off. Well, it works. Now, I'm integrating the help text properly. __uml_setup("root=",uml_root_setup, "root=<file containing the root fs>\n" " This is actually used by the generic kernel in exactly the same\n" " way as in any other kernel. If you configure a number of block\n" " devices and want to boot off something other than ubd0, you \n" " would use something like:\n" " root=/dev/ubd5\n\n" ); Doing it this way allows any source file to declare a command line option, and hook it into the parser, including the help text. Additionally, since all this data is static, and located in one place, it is possible to 'reuse' the memory block. However, I think the host OS will just free that page, and not page it back in, after the system has been up for a bit, so it may not get us that much. |