Re: [Acpi] Re: ACPI fundamental locking problems
At 3:26 AM -0400 2001-07-08, Alexander Viro wrote: >On Sat, 7 Jul 2001, Jamie Lokier wrote: > >> Daniel Phillips wrote: >> > > Reading a tarball is the distillation of what you describe into >> > > efficient form :) >> > >> > /me downloads tar file definition >> > >> > Um, gnu tar or posix tar? or some new, improved tar? >> >> I suggest cpio, which is more compact and in some ways more standard. >> (tar has a silly pad-to-multiple-of-512-byte per file rule, which is >> inappropriate for this). GNU cpio creates cpio format just fine. > >GNU cpio is a race-ridden unmaintained pile of junk. Look at the size >of, say it, Debian patch to upstream source. Then try to read the >patched code. Quite a few of us simply don't have that FPOS on their >boxen. > >Using cpio archive layout is OK, but _please_, don't make it dependent >on GNU cpio. If size is an issue (and of course it is), presumably the archive would be compressed. As long as tar can be convinced to pad with (say) nulls, the padding shouldn't have that much of an impact on archive size. -- /Jonathan Lundell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Sat, 7 Jul 2001, Jamie Lokier wrote: > Daniel Phillips wrote: > > > Reading a tarball is the distillation of what you describe into > > > efficient form :) > > > > /me downloads tar file definition > > > > Um, gnu tar or posix tar? or some new, improved tar? > > I suggest cpio, which is more compact and in some ways more standard. > (tar has a silly pad-to-multiple-of-512-byte per file rule, which is > inappropriate for this). GNU cpio creates cpio format just fine. GNU cpio is a race-ridden unmaintained pile of junk. Look at the size of, say it, Debian patch to upstream source. Then try to read the patched code. Quite a few of us simply don't have that FPOS on their boxen. Using cpio archive layout is OK, but _please_, don't make it dependent on GNU cpio. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
[EMAIL PROTECTED] wrote: > >> Would it be possible to use a cramfs image in vmlinux (i.e. real > >> filesystem image, not an in-kernel-structures fs like ramfs), and map > >> it directly from the kernel image (it would have to be suitably aligned, > >> of course)? > > > Yes that would work, and it would work on machines with less RAM too. > > You would want to remove the cramfs filesystem code when you're done though. > > Until you pxe-boot your kernel over the network I don't see a problem with that. pxe-boot loads vmlinuz, kernel boots and finds cramfs image inside itself. Problem? -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Mike Touloumtzis wrote: > > Yes that would work, and it would work on machines with less RAM too. > > You would want to remove the cramfs filesystem code when you're done though. > > Some of the files in the boot time FS would need to > be kept around, such as the ACPI code, right? Perhaps. They could be copied to a ramfs by the user-space code :-) On this theme, it's just occured to me that the module loader could be taught to map ramfs pages directly to module code/data space. That would save a little memory. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Sat, Jul 07, 2001 at 11:53:29PM +0200, Jamie Lokier wrote: > Mike Touloumtzis wrote: > > > > Would it be possible to use a cramfs image in vmlinux (i.e. real > > filesystem image, not an in-kernel-structures fs like ramfs), and map > > it directly from the kernel image (it would have to be suitably aligned, > > of course)? > > > > This would allow demand paging of files in the image (not too important > > for a minimal boot fs, admittedly), and would allow text pages to be > > dropped under VM pressure (nice for a fs which holds substantial amounts > > of boot-time-only code). > > Yes that would work, and it would work on machines with less RAM too. > You would want to remove the cramfs filesystem code when you're done though. Some of the files in the boot time FS would need to be kept around, such as the ACPI code, right? miket - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]> you wrote: >> Would it be possible to use a cramfs image in vmlinux (i.e. real >> filesystem image, not an in-kernel-structures fs like ramfs), and map >> it directly from the kernel image (it would have to be suitably aligned, >> of course)? > Yes that would work, and it would work on machines with less RAM too. > You would want to remove the cramfs filesystem code when you're done though. Until you pxe-boot your kernel over the network - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Mike Touloumtzis wrote: > > > Doesn't the approach "treat a chunk of data built into bzImage as > > > populated ramfs" look cleaner? No need to fiddle with tar format, > > > no copying data from place to place. > > > > So tell me, how do you populate ramfs without a format which tells you > > what path and which permissions to assign each file? That's exactly > > what tar is. > > Would it be possible to use a cramfs image in vmlinux (i.e. real > filesystem image, not an in-kernel-structures fs like ramfs), and map > it directly from the kernel image (it would have to be suitably aligned, > of course)? > > This would allow demand paging of files in the image (not too important > for a minimal boot fs, admittedly), and would allow text pages to be > dropped under VM pressure (nice for a fs which holds substantial amounts > of boot-time-only code). Yes that would work, and it would work on machines with less RAM too. You would want to remove the cramfs filesystem code when you're done though. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Jamie Lokier writes: > (tar has a silly pad-to-multiple-of-512-byte per file rule, which is > inappropriate for this). If you remember that 'tar' means "tape archiver", and that at the time it was written the standard tape block size was 512 bytes, the rule isn't silly at all, although it may be undesirable overhead for modern uses of 'tar'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Sat, Jul 07, 2001 at 07:34:38AM -0400, Jeff Garzik wrote: > Eugene Crosser wrote: > > > > Doesn't the approach "treat a chunk of data built into bzImage as > > populated ramfs" look cleaner? No need to fiddle with tar format, > > no copying data from place to place. > > So tell me, how do you populate ramfs without a format which tells you > what path and which permissions to assign each file? That's exactly > what tar is. Would it be possible to use a cramfs image in vmlinux (i.e. real filesystem image, not an in-kernel-structures fs like ramfs), and map it directly from the kernel image (it would have to be suitably aligned, of course)? This would allow demand paging of files in the image (not too important for a minimal boot fs, admittedly), and would allow text pages to be dropped under VM pressure (nice for a fs which holds substantial amounts of boot-time-only code). miket - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Daniel Phillips wrote: > > Reading a tarball is the distillation of what you describe into > > efficient form :) > > /me downloads tar file definition > > Um, gnu tar or posix tar? or some new, improved tar? I suggest cpio, which is more compact and in some ways more standard. (tar has a silly pad-to-multiple-of-512-byte per file rule, which is inappropriate for this). GNU cpio creates cpio format just fine. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Saturday 07 July 2001 15:50, Jeff Garzik wrote: > Eugene Crosser wrote: > > In article > > <[EMAIL PROTECTED]>, > > > > Alexander Viro <[EMAIL PROTECTED]> writes: > > >> Doesn't the approach "treat a chunk of data built into bzImage > > >> as populated ramfs" look cleaner? No need to fiddle with tar > > >> format, no copying data from place to place. > > > > > > What the hell _is_ "populated ramfs"? The thing doesn't live in > > > array of blocks. Its directory structure consists of a bunch of > > > dentries. > > > > I am stupid. But the point still stays: having an image of > > pre-populated filesystem (some other than ramfs) that you only need > > to load into RAM seems more sutable than parsing tar format. Maybe > > (probably) I am missing something. > > Yeah -- we build all this stuff dynamically. struct file, struct > inode, etc. You could store them on disk as they would be > represented in memory, but this would be incredibly inefficient > because of all the runtime structures unnecessary on disk, and > because of all the fixups and checks you would have to perform on the > data in the images after they magically appear in memory. Not to mention internal fragmentation. > Reading a tarball is the distillation of what you describe into > efficient form :) /me downloads tar file definition Um, gnu tar or posix tar? or some new, improved tar? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Eugene Crosser wrote: > > In article <[EMAIL PROTECTED]>, > Alexander Viro <[EMAIL PROTECTED]> writes: > > >> Doesn't the approach "treat a chunk of data built into bzImage as > >> populated ramfs" look cleaner? No need to fiddle with tar format, > >> no copying data from place to place. > > > > What the hell _is_ "populated ramfs"? The thing doesn't live in array > > of blocks. Its directory structure consists of a bunch of dentries. > > I am stupid. But the point still stays: having an image of pre-populated > filesystem (some other than ramfs) that you only need to load into > RAM seems more sutable than parsing tar format. Maybe (probably) I am > missing something. Yeah -- we build all this stuff dynamically. struct file, struct inode, etc. You could store them on disk as they would be represented in memory, but this would be incredibly inefficient because of all the runtime structures unnecessary on disk, and because of all the fixups and checks you would have to perform on the data in the images after they magically appear in memory. Reading a tarball is the distillation of what you describe into efficient form :) -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> writes: >> Doesn't the approach "treat a chunk of data built into bzImage as >> populated ramfs" look cleaner? No need to fiddle with tar format, >> no copying data from place to place. > > What the hell _is_ "populated ramfs"? The thing doesn't live in array > of blocks. Its directory structure consists of a bunch of dentries. I am stupid. But the point still stays: having an image of pre-populated filesystem (some other than ramfs) that you only need to load into RAM seems more sutable than parsing tar format. Maybe (probably) I am missing something. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Eugene Crosser wrote: > > In article <[EMAIL PROTECTED]>, > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > I don't like the current initrd very much myself, I have to admit. I'm not > > going to accept a "you have to have a ramdisk" approach - I think the > > ramdisks are really broken. > > > > But I've seen a "populate ramfs from a tar-file built into 'bzImage'" > > patch somewhere, and that would be a whole lot more palatable to me. > > Doesn't the approach "treat a chunk of data built into bzImage as > populated ramfs" look cleaner? No need to fiddle with tar format, > no copying data from place to place. So tell me, how do you populate ramfs without a format which tells you what path and which permissions to assign each file? That's exactly what tar is. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On 7 Jul 2001, Eugene Crosser wrote: > Doesn't the approach "treat a chunk of data built into bzImage as > populated ramfs" look cleaner? No need to fiddle with tar format, > no copying data from place to place. What the hell _is_ "populated ramfs"? The thing doesn't live in array of blocks. Its directory structure consists of a bunch of dentries. Permissions/ownership/timestamps are in a bunch of struct inode - sitting in icache and allocated in normal way. Regular files are entirely in pagecache, ditto for symlinks. Ramfs has no backing store. At all. That's precisely what remains of filesystem if you take backing store away - everything is in VFS/VM caches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> writes: > I don't like the current initrd very much myself, I have to admit. I'm not > going to accept a "you have to have a ramdisk" approach - I think the > ramdisks are really broken. > > But I've seen a "populate ramfs from a tar-file built into 'bzImage'" > patch somewhere, and that would be a whole lot more palatable to me. Doesn't the approach "treat a chunk of data built into bzImage as populated ramfs" look cleaner? No need to fiddle with tar format, no copying data from place to place. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Friday 06 July 2001 13:16, Alan Cox wrote: > > I am convinced. I misunderstood, thinking there was a big change just > > for > > ACPI which I and many others don't use. Thanks for clearing things up. > > It solves a few long standing arguments too - we can slap .config in it > ending the long standing /proc/config argument without using any ram except > when people care The same for System.map -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
> I am convinced. I misunderstood, thinking there was a big change just > for > ACPI which I and many others don't use. Thanks for clearing things up. It solves a few long standing arguments too - we can slap .config in it ending the long standing /proc/config argument without using any ram except when people care - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Linus Torvalds wrote: > You would never even know the difference. You'd do a "make bzImage", and > the default filesystem would just be embedded into the image. By default > it probably doesn't need to do much - although things like the BIOS DPMI > scan etc would surely be good to get rid of. > > Why complain about that? I am convinced. I misunderstood, thinking there was a big change just for ACPI which I and many others don't use. Thanks for clearing things up. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
> >Nope. > >I do not want to maintain two interfaces. If we make user space the way to >do these things, then we will do pretty much most of the driver setup etc >in user space. We'd have to: we'd enter user space before drivers have had >a chance to initialize, exactly because "features like these" can change >the device mappings etc. > >And I don't want to have two completely different bootup paths. I agree. Also, having this userland step would help for things like booting from an FireWire or USB hard disk. I hacked the SBP2 (FW) driver to be useable as a boot device, but this involved adding an ugly schedule() loop for a couple of seconds before mouting root in order to leave some time for the drive to be probed. Also, on such dynamic busses, you can't really know which device major/minor a given drive will be assigned. Having a userland mecanism here would allow waiting for all devices to be probed, reading of the disk GUID (on fw at least) to figure out where is the real root device, etc... Even displaying a nice UI to let the user pick a root device is none is found, etc... So your idea fixes more than just the ACPI problems ;) Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Jeff writes: > I've always thought it would be neat to do: > > cat bzImage initrd.tar.gz > vmlinuz > rdev --i-have-a-tarball-piggyback vmlinuz > > Linking into the image is easy for hackers, but why not make it > scriptable and super-easy for end users? x86 already has the rdev > utility to mark a kernel image as having certain flags. It could even > be a command line option, "inittgz" or somesuch, telling us that a > gzip-format tarball immediately follows the end of our ELF image. This would be especially handy for network booting: you only need to send the one file to the client, and it boots the kernel and loads the initrd without any extra requests/parameters/configuration needed. > I wonder if any bootloader mods would be needed at all to do this... > AFAICS you just need to make sure the kernel doesn't trample the > piggyback'd data. Probably not - the kernel would handle all of it. It sounds like Linus and Al are in favour of this, so it will likely be in 2.5.early. Having the tar be extracted into ramfs has the added benefit that you don't need to 'pre-configure' ramdisk size, make dd initrd images, or waste memory that is representing empty fs space. Conversely, if the root is ramfs you also don't need to worry about the ramdisk fs being too small if you need to create some temprary files there... It is a win in all cases. Cheers, Andreas -- Andreas Dilger Turbolinux filesystem development http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Thu, 5 Jul 2001, Helge Hafting wrote: > > I am fine with "You have to use initrd (or similiar) _if_ you want this > feature." Nope. I do not want to maintain two interfaces. If we make user space the way to do these things, then we will do pretty much most of the driver setup etc in user space. We'd have to: we'd enter user space before drivers have had a chance to initialize, exactly because "features like these" can change the device mappings etc. And I don't want to have two completely different bootup paths. > But please don't make initrd mandatory for those of us who don't > need ACPI, don't need dhcp before mounting disks and so on. You would never even know the difference. You'd do a "make bzImage", and the default filesystem would just be embedded into the image. By default it probably doesn't need to do much - although things like the BIOS DPMI scan etc would surely be good to get rid of. Why complain about that? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Thu, 5 Jul 2001, Helge Hafting wrote: > Linus Torvalds wrote: > [...] > > We migth want to just make initrd a built-in thing in the kernel, > > something that you simply cannot avoid. A lot of these things (ie dhcp for > > NFS root etc) are right now done in kernel space, simply because we don't > > want to depend on initrd, and people want to use old loaders. > > > > I don't like the current initrd very much myself, I have to admit. I'm not > > going to accept a "you have to have a ramdisk" approach - I think the > > ramdisks are really broken. > > > > But I've seen a "populate ramfs from a tar-file built into 'bzImage'" > > patch somewhere, and that would be a whole lot more palatable to me. > > > > If anybody were to send me a patch that just unconditionally does this, I > > would probably not be adverse to putting it into 2.5.x. We have all the > > infrastructure to make all this a lot cleaner than it used to be (ie the > > "pivot_root()" stuff etc means that we can _truly_ do things from user > > mode, with no magic kernel flags). Open 2.5 and I'm starting to feed that stuff in pieces... > I am fine with "You have to use initrd (or similiar) _if_ you want this > feature." "Similar" == ramfs. > But please don't make initrd mandatory for those of us who don't > need ACPI, don't need dhcp before mounting disks and so on. How about "don't want to keep special-case code for mounting root in your kernel"? It's more than ramfs, BTW, and rm(1) on ramfs frees memory just fine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
> But please don't make initrd mandatory for those of us who don't > need ACPI, don't need dhcp before mounting disks and so on. > > I hope the "fs-less" kernel image still will be possible for those > of us who have a simple setup. If we can do that kind of early boot user space then stuff like finding the root file system and possibly even the initial pnpbios scanners belong in user space. So you would want it for all boxes. Equally you would want it to be completely trivial - it has to be a case of a default make bzImage popping out a completely perfect base initrd and make bzLilo adding both - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Helge Hafting wrote: > I am fine with "You have to use initrd (or similiar) _if_ you want this > feature." > But please don't make initrd mandatory for those of us who don't > need ACPI, don't need dhcp before mounting disks and so on. I've always thought it would be neat to do: cat bzImage initrd.tar.gz > vmlinuz rdev --i-have-a-tarball-piggyback vmlinuz Linking into the image is easy for hackers, but why not make it scriptable and super-easy for end users? x86 already has the rdev utility to mark a kernel image as having certain flags. It could even be a command line option, "inittgz" or somesuch, telling us that a gzip-format tarball immediately follows the end of our ELF image. I wonder if any bootloader mods would be needed at all to do this... AFAICS you just need to make sure the kernel doesn't trample the piggyback'd data. -- Jeff Garzik | Thalidomide, eh? Building 1024| So you're saying the eggplant has an accomplice? MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Linus Torvalds wrote: [...] > We migth want to just make initrd a built-in thing in the kernel, > something that you simply cannot avoid. A lot of these things (ie dhcp for > NFS root etc) are right now done in kernel space, simply because we don't > want to depend on initrd, and people want to use old loaders. > > I don't like the current initrd very much myself, I have to admit. I'm not > going to accept a "you have to have a ramdisk" approach - I think the > ramdisks are really broken. > > But I've seen a "populate ramfs from a tar-file built into 'bzImage'" > patch somewhere, and that would be a whole lot more palatable to me. > > If anybody were to send me a patch that just unconditionally does this, I > would probably not be adverse to putting it into 2.5.x. We have all the > infrastructure to make all this a lot cleaner than it used to be (ie the > "pivot_root()" stuff etc means that we can _truly_ do things from user > mode, with no magic kernel flags). > I am fine with "You have to use initrd (or similiar) _if_ you want this feature." But please don't make initrd mandatory for those of us who don't need ACPI, don't need dhcp before mounting disks and so on. I hope the "fs-less" kernel image still will be possible for those of us who have a simple setup. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
On Wed, 4 Jul 2001, Alan Cox wrote: > > > I argued this at the very beginning, but there was a very strong > > view that you needed to run most of the code before you had a user > > space to run it in. I've not followed things closely enough to > > That bit is clearly untrue. It's untrue only in the sense of "it is technically possible to do it", but it _is_ true that right now it's not very convenient to set up an easy initrd system. We migth want to just make initrd a built-in thing in the kernel, something that you simply cannot avoid. A lot of these things (ie dhcp for NFS root etc) are right now done in kernel space, simply because we don't want to depend on initrd, and people want to use old loaders. I don't like the current initrd very much myself, I have to admit. I'm not going to accept a "you have to have a ramdisk" approach - I think the ramdisks are really broken. But I've seen a "populate ramfs from a tar-file built into 'bzImage'" patch somewhere, and that would be a whole lot more palatable to me. If anybody were to send me a patch that just unconditionally does this, I would probably not be adverse to putting it into 2.5.x. We have all the infrastructure to make all this a lot cleaner than it used to be (ie the "pivot_root()" stuff etc means that we can _truly_ do things from user mode, with no magic kernel flags). But if we do this, then we should _truly_ get rid of all the root device etc setup crap (and the "search for init" etc stuff - it _is_ going to be there, and THAT process is the one that should then search for the real init once it has booted). That, together with reasonable interfaces to let ACPI set irq data for the kernel etc, might make moving ACPI back into user space possible in _practice_ and not just in theory. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
> I argued this at the very beginning, but there was a very strong > view that you needed to run most of the code before you had a user > space to run it in. I've not followed things closely enough to That bit is clearly untrue. > My feeling has been that ACPI has violated the minimum privilege > concept from the beginning, although I think putting stuff in drivers > that could be at user level is not htat uncommon in Linux. It still seems to lack even basic checks that the writes AML does are into E820 NV or device space only - also while fixing it the ACPI guys might note that a write close to 0x will lead to a failed ioremap and a nasty mess because they ioremap a fixed sized window that will wrap - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Acpi] Re: ACPI fundamental locking problems
> From: Alan Cox [SMTP:[EMAIL PROTECTED]] > > The goal isnt a technical nit, its to avoid loading 300Kbytes of crud > (which > should mostly be in user space anyway) on the 99.9% of machines where we > dont > need it. [DJW:] I argued this at the very beginning, but there was a very strong view that you needed to run most of the code before you had a user space to run it in. I've not followed things closely enough to know whether or not this is really true and whether or not it is inevitable, or just a flaw in the ACPI design. My feeling has been that ACPI has violated the minimum privilege concept from the beginning, although I think putting stuff in drivers that could be at user level is not htat uncommon in Linux. -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI fundamental locking problems
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > BTW of course ACPI can be turned off via make menuconfig. > > Can you point me to the name of the option? I can't find it on my IA64 ACPI is required for IA64 to boot, so you can't disable it AFAIK. Sorry, I should have included that caveat in my previous message. -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]> you wrote: >> walking into their top secret menwith hill base playing the >> mission impossible >> theme tune then chaining themselves to things.. > You're kidding.right? > BTW of course ACPI can be turned off via make menuconfig. Can you point me to the name of the option? I can't find it on my IA64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
> This goes to the special nature of the Global Lock. If we cannot acquire it, > we set a bit, and the system interrupts when it is released. Please see > acpi_ev_acquire_global_lock(). Gotcha..now I follow - I read it as acquire or spin not acquire or fail > > if you make a callback from the ACPI code - eg power > > management that itself > > needs to call AML code ? > > All we do at interrupt level is signal the semaphore that threads needing > the GL have blocked on. They continue execution at non-interrupt level. Obvious question - you call kmalloc with that lock held - that can sleep as it is GFP_KERNEL so other threads can run and make acpi calls .. I assume the other threads block on the acpi lock, and the kmalloc eventually returns. > > Microsoft very early on in debugging Win2K problems ask > > people to use non > > ACPI settings. > > What is your source for this? They certainly could have said that, but > everything I've heard is that MS was so committed to ACPI, they almost left > APM support out of W2K. Microsoft helpdesk engineers I know (contrary to assumptions from some quarters there is a lot of respect between some of the MS and linux folks for each others work) > 3) ACPI increases visibility of vendor code. You can disassemble AML. You > can step through it with our debugger. Well actually the license on the intel bios says not. Of course the license is invalid here but nevertheless.. > > Governments. They'd hate the US to get prior warning of say protestors > > walking into their top secret menwith hill base playing the > > mission impossible > > theme tune then chaining themselves to things.. > > You're kidding.right? No. There are people more paranoid than I care to consider sane. They have lots of money. There are also a bunch of greenpeace people who today walked straight into a US top secret base in the UK singing the mission impossible theme tune .. which did you doubt ? [Come to think of it which do you find the more improbable ..] Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI fundamental locking problems
Some of this discussion's getting a little X-Files-y. However, there are some points I'd like to touch on... > From: Alan Cox [mailto:[EMAIL PROTECTED]] > Well lets take a look at the asm shall we > 1.It doesnt have a seperate loop when it fails to take the lock > polling it (See intels own docs on spin locks). You do read your > own publications ? This goes to the special nature of the Global Lock. If we cannot acquire it, we set a bit, and the system interrupts when it is released. Please see acpi_ev_acquire_global_lock(). > 2.It should be using rep nop (See your own Intel PIV > publications) > 3.Should be asm __volatile__ or gcc can move it You are most likely right about all this stuff. Haven't had the need to fix it because it's been working fine. Patches accepted. > I am also somewhat puzzled about contexts here. What happens > if you take > an IRQ during the global lock acquire and want to do ACPI. > What happens > if you make a callback from the ACPI code - eg power > management that itself > needs to call AML code ? All we do at interrupt level is signal the semaphore that threads needing the GL have blocked on. They continue execution at non-interrupt level. > I am assuming the ACPI stuff has no IRQ level execution > ability, but are you > sure ACPI never calls a single code path that can require an > ACPI operation > from a callback - eg the PM layer ? Otherwise how can you be > sure there won't > be any priority inversions between the bios/acpi locking set > and the kernel > locking set We're aware of this issue and have coded accordingly. We have run into these issues (specifically with the Embedded Controller driver) and we fix them when they crop up. > Microsoft very early on in debugging Win2K problems ask > people to use non > ACPI settings. What is your source for this? They certainly could have said that, but everything I've heard is that MS was so committed to ACPI, they almost left APM support out of W2K. > > Jeff Garzik: > > The difference with ACPI is that vendors can write code > that is executed > > in the kernel's context (instead of what you can consider the BIOS's > > context). That is a whole new can of worms. (I know I'm replying to Jeff's point in your email, sorry) 1) Vendors can write code that is *interpreted* by the OS. 2) If vendors write a malicious BIOS, it's game over even without ACPI 3) ACPI increases visibility of vendor code. You can disassemble AML. You can step through it with our debugger. > For security reasons alone we need to ensure ACPI can be > firmly in the off > position. Executing US written binary code in the Linux > kernel will not be > acceptable to european corporations, non US military bodies and most > Governments. They'd hate the US to get prior warning of say protestors > walking into their top secret menwith hill base playing the > mission impossible > theme tune then chaining themselves to things.. You're kidding.right? BTW of course ACPI can be turned off via make menuconfig. > And we have customers who pointedly don't talk to the BIOS > and kill SMI/SMM > early on... And from what I understand, Itanium doesn't necessarily have a Global Lock either. Great, no problem. However, we still need to handle machines that do. Regards -- Andy PS Have I read *all* the Intel pubs? Cover to cover? Um, no. ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
Other ACPI problems, that come with the increased potential for malicious code: - Much easier for NSA to snoop machine activity undetected (hello paranoid people) - Much easier to write worms and virii and similar (it's much easier for someone malicious to patch an acpi table than bios binary code.) -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI fundamental locking problems
On Tue, 3 Jul 2001, Grover, Andrew wrote: > We're depending on vendors (aka the BIOS) for all the ACPI tables, as well > as every other piece of a priori data we need to boot the OS. And this is the part that I find terrifying. The minute we rely on BIOS vendors, they seem to find wonderful new ways to screw things up royally. > Could I please ask that you at least show me a system where this is a > problem before throwing out all the work we've done on ACPI because of this > technical nit? Currently, with what we extract from BIOS space, we can blacklist/whitelist according to DMI entries. With ACPI providing AML code that's executed in kernel space, there's no telling what could happen. The whole "black box, you don't need to know how this works, just call it" approach is scary. With ACPI having access to IDE taskfile commands, the possibilities for all sorts of evil exist. Just when we thought the CPRM nightmare was over, we have the BIOS feeding us IDE commands to throw at drives with vendors telling us "Trust it, it's ok, really." Maybe I'm overly paranoid, but I'm sure I'm not the only one who feels this way. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
> > That is the case here. The Global Lock is for synchronizing accesses between > > the OS (that's us) and the firmware (SMI). Normal spinlocks are for intra-OS > > locking. Here, we're synchronizing access with the BIOS. It's different. > > I realize what the purpose of the global lock is... > > How is the asm code in ACPI_ACQUIRE_GLOBAL_LOCK specific to interaction > between OS and SMI? Well lets take a look at the asm shall we 1. It doesnt have a seperate loop when it fails to take the lock polling it (See intels own docs on spin locks). You do read your own publications ? 2. It should be using rep nop (See your own Intel PIV publications) 3. Should be asm __volatile__ or gcc can move it I am also somewhat puzzled about contexts here. What happens if you take an IRQ during the global lock acquire and want to do ACPI. What happens if you make a callback from the ACPI code - eg power management that itself needs to call AML code ? I am assuming the ACPI stuff has no IRQ level execution ability, but are you sure ACPI never calls a single code path that can require an ACPI operation from a callback - eg the PM layer ? Otherwise how can you be sure there won't be any priority inversions between the bios/acpi locking set and the kernel locking set > > All this code has been working for as long as I can remember. > > ;-) Under Windows? Irrelevant. Linux uses the hardware totally Microsoft very early on in debugging Win2K problems ask people to use non ACPI settings. > The difference with ACPI is that vendors can write code that is executed > in the kernel's context (instead of what you can consider the BIOS's > context). That is a whole new can of worms. For security reasons alone we need to ensure ACPI can be firmly in the off position. Executing US written binary code in the Linux kernel will not be acceptable to european corporations, non US military bodies and most Governments. They'd hate the US to get prior warning of say protestors walking into their top secret menwith hill base playing the mission impossible theme tune then chaining themselves to things.. And if the NSA wants the US goverment to execute binary only chinese bios code on all their critical systems I am sure people will be happy. > Look at the Linux boot sequence, which Randy Dunlap documented. We > collect as much information as is reasonable from BIOS at startup, so we > won't have to talk to it again at runtime. And we have customers who pointedly don't talk to the BIOS and kill SMI/SMM early on... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
"Grover, Andrew" wrote: > > > From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > > events/evxface.c:610:acpi_acquire_global_lock -> > > events/evmisc.c:337:acpi_ev_acquire_global_lock -> > > include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK > > > > My immediate objections are, > > (a) acgcc.h is re-implementing spinlocks in a non-standard, > > non-portable, and expensive way, and (b) this entire code path is > > incredibly expensive. > > Well, when I look at other Linux code, I assume that if it does something > weird, it does it for a reason. > > That is the case here. The Global Lock is for synchronizing accesses between > the OS (that's us) and the firmware (SMI). Normal spinlocks are for intra-OS > locking. Here, we're synchronizing access with the BIOS. It's different. I realize what the purpose of the global lock is... How is the asm code in ACPI_ACQUIRE_GLOBAL_LOCK specific to interaction between OS and SMI? > All this code has been working for as long as I can remember. ;-) Under Windows? Irrelevant. Linux uses the hardware totally differently from Windows. Under Linux? You cannot come close to saying CONFIG_ACPI is used by a large number of users... I don't think that claim can really be made yet. > You mention twice that it is "expensive". Keeping in mind the 80-20 rule, in > what way do you find this code costly? Compare your x86 asm code with the spinlock asm code. More importantly, why is a spinlock or other kernel intrinsic avoided in acgcc.h? It's much less portable this way. > > But my fundamental objection is, > > we are depending on vendors to get locking right in their > > ACPI tables. > > And assume by some magic or design that said locking works > > with whatever > > unrelated kernel locking is going on. > > By design, it works. We get to slipstream Windows a little here in that > vendors need to have a working Global Lock interface to pass WHQL. (1) A working lock interface does not imply that -users- of the lock interface are correct (2) Nobody here puts stock in Windows tests, which I'm assuming the WHQL is. > > It is my initial belief that a smaller info query interface that can > > parse useful ACPI would be more effective. For times like > > suspend/resume where we would want to execute control methods, well, > > there's always the disasm -> write-small-driver cycle. Who knows if > > this is a realistics proposed solution. But it really scares me to > > depend on vendors to get locking right. > > We're depending on vendors (aka the BIOS) for all the ACPI tables, as well > as every other piece of a priori data we need to boot the OS. The difference with ACPI is that vendors can write code that is executed in the kernel's context (instead of what you can consider the BIOS's context). That is a whole new can of worms. > Could I please ask that you at least show me a system where this is a > problem before throwing out all the work we've done on ACPI because of this > technical nit? ACPI is so new I do not think this is necessary. I am reading straight from the spec, the same thing system implementors will read. Anyway, for the main point, which you missed: The global lock is not ONLY for SMM type stuff. The vendor can use it in control methods all over the place. And the vendor can just as easily screw up it up. I do not trust a bios vendor to get runtime OS locking correct... and that is -totally- different from trusting the BIOS to provide us with a tiny bit of information. Look at the Linux boot sequence, which Randy Dunlap documented. We collect as much information as is reasonable from BIOS at startup, so we won't have to talk to it again at runtime. Jeff -- Jeff Garzik | "I respect faith, but doubt is Building 1024| what gives you an education." MandrakeSoft | -- Wilson Mizner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
On Tue, Jul 03, 2001, Jeff Garzik <[EMAIL PROTECTED]> wrote: > I was reading through the ACPI spec, to see what was required to obtain > the IRQ routing table from AML. FWIW, ia64 already does this, if you're looking for the code to do it. JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI fundamental locking problems
> We're depending on vendors (aka the BIOS) for all the ACPI tables, as well > as every other piece of a priori data we need to boot the OS. They have had enough problems getting simpler API's right. The ACPI spec is bloated, complex, and very hard to follow - and its written in my native language. I really do not envy a random BIOS writers task. > Could I please ask that you at least show me a system where this is a > problem before throwing out all the work we've done on ACPI because of this > technical nit? The goal isnt a technical nit, its to avoid loading 300Kbytes of crud (which should mostly be in user space anyway) on the 99.9% of machines where we dont need it. The user space thing isnt an idle comment btw, its something that I think we should actively pursue for 2.5. By making better use of initrd and the clean ramfsroot stuff Al wants to do we can push a lot of stuff (bootp, dhcp, dmi based configuration fixups, acpi) almost entirely into user space. That makes me a lot lot happier. The fact that it takes more code to parse and interpret ACPI than it does to route traffic on the internet backbones should be a hint something is badly wrong either in ACPI the spec, ACPI the implenentation or both. Reading the code I can find some examples of pointless code bloat, but not enough to convince me the broken part isnt the spec. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI fundamental locking problems
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > events/evxface.c:610:acpi_acquire_global_lock -> > events/evmisc.c:337:acpi_ev_acquire_global_lock -> > include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK > > My immediate objections are, > (a) acgcc.h is re-implementing spinlocks in a non-standard, > non-portable, and expensive way, and (b) this entire code path is > incredibly expensive. Well, when I look at other Linux code, I assume that if it does something weird, it does it for a reason. That is the case here. The Global Lock is for synchronizing accesses between the OS (that's us) and the firmware (SMI). Normal spinlocks are for intra-OS locking. Here, we're synchronizing access with the BIOS. It's different. All this code has been working for as long as I can remember. You mention twice that it is "expensive". Keeping in mind the 80-20 rule, in what way do you find this code costly? > But my fundamental objection is, > we are depending on vendors to get locking right in their > ACPI tables. > And assume by some magic or design that said locking works > with whatever > unrelated kernel locking is going on. By design, it works. We get to slipstream Windows a little here in that vendors need to have a working Global Lock interface to pass WHQL. > It is my initial belief that a smaller info query interface that can > parse useful ACPI would be more effective. For times like > suspend/resume where we would want to execute control methods, well, > there's always the disasm -> write-small-driver cycle. Who knows if > this is a realistics proposed solution. But it really scares me to > depend on vendors to get locking right. We're depending on vendors (aka the BIOS) for all the ACPI tables, as well as every other piece of a priori data we need to boot the OS. Could I please ask that you at least show me a system where this is a problem before throwing out all the work we've done on ACPI because of this technical nit? Thanks -- Regards -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
