Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-08 Thread Jonathan Lundell
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-08 Thread Alexander Viro
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-08 Thread Alexander Viro
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-08 Thread Jonathan Lundell
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,

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
[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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
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.

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Mike Touloumtzis
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread arjan
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,

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
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 > >

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Steve VanDevender
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Mike Touloumtzis
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Daniel Phillips
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jeff Garzik
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Eugene Crosser
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jeff Garzik
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Alexander Viro
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.

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Eugene Crosser
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Eugene Crosser
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Alexander Viro
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jeff Garzik
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Eugene Crosser
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jeff Garzik
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Daniel Phillips
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Mike Touloumtzis
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Steve VanDevender
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread arjan
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Mike Touloumtzis
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
[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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-07 Thread Jamie Lokier
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Daniel Phillips
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Alan Cox
> 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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Helge Hafting
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. >

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Benjamin Herrenschmidt
> >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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Benjamin Herrenschmidt
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Helge Hafting
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Alan Cox
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-06 Thread Daniel Phillips
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Andreas Dilger
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 >

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Linus Torvalds
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Alexander Viro
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Alan Cox
> 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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Jeff Garzik
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Helge Hafting
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Helge Hafting
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Jeff Garzik
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Alexander Viro
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Linus Torvalds
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.

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-05 Thread Alan Cox
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-04 Thread Linus Torvalds
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-04 Thread Alan Cox
> 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

RE: [Acpi] Re: ACPI fundamental locking problems

2001-07-04 Thread Dave J Woolley
> 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

RE: [Acpi] Re: ACPI fundamental locking problems

2001-07-04 Thread Dave J Woolley
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-04 Thread Alan Cox
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

Re: [Acpi] Re: ACPI fundamental locking problems

2001-07-04 Thread Linus Torvalds
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

RE: ACPI fundamental locking problems

2001-07-03 Thread Grover, Andrew
> 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

Re: ACPI fundamental locking problems

2001-07-03 Thread arjan
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Alan Cox
> 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

RE: ACPI fundamental locking problems

2001-07-03 Thread Grover, Andrew
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Jeff Garzik
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

RE: ACPI fundamental locking problems

2001-07-03 Thread Dave Jones
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Alan Cox
> > 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... >

Re: ACPI fundamental locking problems

2001-07-03 Thread Jeff Garzik
"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: ACPI fundamental locking problems

2001-07-03 Thread Johannes Erdfelt
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Alan Cox
> 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

RE: ACPI fundamental locking problems

2001-07-03 Thread Grover, Andrew
> 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

RE: ACPI fundamental locking problems

2001-07-03 Thread Grover, Andrew
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,

Re: ACPI fundamental locking problems

2001-07-03 Thread Johannes Erdfelt
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Jeff Garzik
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Jeff Garzik
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

RE: ACPI fundamental locking problems

2001-07-03 Thread Dave Jones
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

Re: ACPI fundamental locking problems

2001-07-03 Thread arjan
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

RE: ACPI fundamental locking problems

2001-07-03 Thread Grover, Andrew
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Alan Cox
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

RE: ACPI fundamental locking problems

2001-07-03 Thread Grover, Andrew
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Alan Cox
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

Re: ACPI fundamental locking problems

2001-07-03 Thread Alan Cox
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