Re: how to let all others run
Hi Oliver! Oliver Neukum <[EMAIL PROTECTED]> writes: > is there a way to let all other runable tasks run until they block > or return to user space, before the task wishing to do so is run > again ? Are you trying to do this in kernel or something? From userspace you can use nice(2) then sched_yield(2), though I don't know if the linux implementations will guarrantee anything. -- http://www.penguinpowered.com/~vii - 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: how to let all others run
"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > On 4 Apr 2001, John Fremlin wrote: > > > > Hi Oliver! > > > > Oliver Neukum <[EMAIL PROTECTED]> writes: > > > > > is there a way to let all other runable tasks run until they block > > > or return to user space, before the task wishing to do so is run > > > again ? > > > > Are you trying to do this in kernel or something? From userspace you > > can use nice(2) then sched_yield(2), though I don't know if the linux > > implementations will guarrantee anything. > > > > I recommend using usleep(0) instead of sched_yield(). Last time I > checked, sched_yield() seemed to spin and eat CPU cycles, usleep(0) > always gives up the CPU. What is wrong with this? sched_yield only yields to processes with lower priority (hence suggestion to use nice(2)). Does sched_yield() fail to yield in cases when a higher priority process wants to run? usleep() wastes time if no other such process is waiting, surely? [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
> This is not correct, because we want the power button to be
> configurable. The user should be able to redefine the power
> button's action, perhaps to only sleep the system. We currently
> surface button events to acpid, which then can do the right thing,
> including a shutdown -h now (which I assume notifies init).
That's just fine and dandy, but
[...]
> > + printk ("acpi: Power button pressed!\n");
[...]
> > + printk("acpi: Sleep button pressed!\n");
Do you think you could keep the above part of the patch? It would be
nice to know how much of ACPI was actually working ;-)
[...]
--
http://www.penguinpowered.com/~vii
-
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: Let init know user wants to shutdown
John R Lenton <[EMAIL PROTECTED]> writes: [...] > Just today a friend saw my box shutdown via the powerbutton and > wondered if he coudln't set his up to trigger a different event > (actually two: he wanted his sister - the guilty party - zapped, and > a webcam shot of her face to prove it)... That is in fact possible (given that you have the zapper) on certain hardware with my pmpolicy patch http://john.snoop.dk/programs/linux/offbutton It uses APM instead of ACPI because ACPI doesn't work on my computer. I have an updated version of the patch for 2.4.2, but I haven't got round to uploading it. -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > > > This is not correct, because we want the power button to be > > configurable. The user should be able to redefine the power > > button's action, perhaps to only sleep the system. We currently > > surface button events to acpid, which then can do the right thing, > > including a shutdown -h now (which I assume notifies init). > > There's no problem with configurability -- you can configure init as > well. I saw it pretty much analogic to situation with Ctrl-Alt-Del: > it also sends signal to init. Init then decides what to do. [I > believe requiring acpid for such easy stuff is not neccessary...] Using a signal to hit init with is a bit dubious because most signals are hooked up for something else already. For example, SIGTERM sent to my init (http://john.snoop.dk/programs/linux/jinit) would shutdown and start sulogin, which is probably not what you want when you press the off button. The FreeBSD init is similar FWIW (goes to single user mode). Some PM interfaces (e.g. APM) require a descision to be made by software on such an event (to turn off or to "reject"). IMHO the best way to do this is to exec a small script from kernelspace to get the user's preferred policy; this is lighter weight than a daemon, doesn't require some nasty magic number interface, and can be easily programmed by any admin knowing sh or perl or whatever. [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> > > > + printk ("acpi: Power button pressed!\n");
> >
> > [...]
> >
> > > > + printk("acpi: Sleep button pressed!\n");
> >
> > Do you think you could keep the above part of the patch? It would be
> > nice to know how much of ACPI was actually working ;-)
> I'm hesitant to do this, since 1) You can put those printk's in
> yourself to find out if your particular system is working and 2) You
> can just cat /proc/sys/event, hit a button, and you should see
> output if it works.
Hmm. Pavel Machek could hardly be described as a newbie at hacking
stuff, and yet he says, "I hunted bug for few hours, thinking that
kernel does not get the event at all."
The printks are certainly clearer than cat'ing some binary garbage to
the console and will help out the casual user who doesn't want to
recompile kernel and reboot just to discover that the damn thing
doesn't work.
[...]
--
http://www.penguinpowered.com/~vii
-
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: PATCH(?): linux-2.4.4-pre2: fork should run child first
"Adam J. Richter" <[EMAIL PROTECTED]> writes: [...] > It turned out that the particular unix-like system on which > these benchmarks were taken had a version of fork that did not run > the child first. As it was explained to me then, most of the time, > the child process from a fork will do just a few things and then do > an exec(), releasing its copy-on-write references to the parent's > pages, and that is the big win of copy-on-write for fork() in practice. > This oversight was considered a big embarassment for the operating > system in question, so I won't name it here. > > Guess why you're seeing this email. That's right. Linux-2.4.3's > fork() does not run the child first. Not always, if I understand correctly. Setting to always is putting policy in kernel in a small way. If an app wants to fork and exec, it should use *vfork* and exec, which is a performance win across many OSs because the COW mappings don't even have to be set up, IIRC. [...] -- http://www.penguinpowered.com/~vii - 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: PATCH(?): linux-2.4.4-pre2: fork should run child first
"Adam J. Richter" <[EMAIL PROTECTED]> writes: > "John Fremlin" <[EMAIL PROTECTED]> writes: > > "Adam J. Richter" <[EMAIL PROTECTED]> writes: > >>Guess why you're seeing this email. That's right. Linux-2.4.3's > >> fork() does not run the child first. > > >[...] If an app wants to fork and exec, it > >should use *vfork* and exec, which is a performance win across many > >OSs because the COW mappings don't even have to be set up, IIRC. > > Even in that case, you want to run the child first because The parent is not allowed to run until the child execs, if I understand correctly. Read up on CLONE_VFORK. [...] > Of course, in the vfork case, this change is probably only a very > small win. The real advantage is with regular fork() followed by an > exec, which happens quite a lot. For example, I do not see vfork > anywhere in the bash sources. If it is a real advantage you can get a bigger advantage by changing the app to use vfork, i.e. you can solve the problem (if it exists) better without hacking the kernel. Further, your change will hurt those apps which expect the parent to be given a fair chance, so you'll need to add a fairfork(2) syscall to comply with Californian anti age discrimmination legislation (humour). In fact, if you think fork+exec is such a big performance hit why not go for spawn(2) and have Linus and Al jump on you? ;-) [...] -- http://www.penguinpowered.com/~vii - 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: [new PATCH] Re: 8139too: defunct threads
Andrew Morton <[EMAIL PROTECTED]> writes:
[...]
> None of these will work. The problems with globally setting
> exit_signal to SIGCHLD are that
>
> a) If the parent does waitpid(pid, status, __WCLONE), the
>waitpid will fail. request_module() does this. I don't
>know _why_ it does this. Maybe it's bogus. There is no
>explanation.
waitpid doesn't work on cloned children unless you put in __WCLONE or
__WALL, so this was necessary to catch the child at all. If you set to
use SIGCHLD this will no longer be needed (if I understand correctly).
[...]
> So it seems that we must reparent the thread to init, and
> make sure that it delivers SIGCHLD to init when it exits.
Sounds good. Why isn't SIGCHLD a stronger default anyway.
[...]
> + /* Set the exit signal to SIGCHLD so we signal init on exit */
> + if (this_task->exit_signal ! 0) {
Tyop.
> + printk(KERN_ERR "task `%s' exit_signal %d in daemonize()\n",
> + this_task->comm, this_task->exit_signal);
> + }
> + this_task->exit_signal = SIGCHLD;
> +
> + write_unlock_irq(&tasklist_lock);
> }
>
> void __init init_idle(void)
>
--
http://www.penguinpowered.com/~vii
-
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: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: > > From: Pavel Machek [mailto:[EMAIL PROTECTED]] > > There are 32 signals, and signals can carry more information, if > > required. I really think doing it way UPS-es are done is right > > approach. > I would think that it would make sense to keep shutdown with all the > other power management events. Perhaps it will makes more sense to > handle UPS's through the power management code. I'm happy add UPS functionality to the pmpolicy patch, if someone were willing to test it - as I have no UPS ;-) [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: > Hi Pavel, > > I think init is doing a perfect job WRT UPSs because this is a > trivial application of power management. init wasn't really meant > for this. According to its man page: > > "init...it's primary role is to create processes from a script in > the file /etc/inittab...It also controls autonomous processes > required by any particular system" > > We are going to need some software that handles button events, as > well as thermal events, battery events, polling the battery, AC > adapter status changes, sleeping the system, and more. Dealing with events should be disjoint from polling the battery or powerstatus. Many processes might reasonably simultaneously want to provide a display to the user of the current power status. However, button presses and so on should be handled by a single process. Otherwise the kernel is unreasonably complicated by having to deal with multiple processes' veto power, which could just as well and more flexibly be handled in userspace. I don't why there needs to be an additional daemon constantly running to deal with button presses and power status changes. Apparently init is already handling similar things: why should it not be extended to include button presses? Alternatively, why not forgo a daemon altogether? (This scheme is already implemented in the pmpolicy patch, i.e. it is already working.) > We need WAY more flexibility than init provides. Examples please. [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: > [do we want to move this to linux-power?] I'm happy to as long as I'm cc'd. [...] IMHO the pm interface should be split up as following: (1) Battery status, power status, UPS status polling. It should be possible for lots of processes to do this simultaneously. [That does not prohibit a single process querying the kernel and all the others querying it.] (2) Funky events happening to the physical machine, like a button being pressed, the case being closed, etc. [Should this include battery low warnings, power status changes? I don't know.] (3) Sending the machine to sleep, turning it off. It should be possible to do this from userspace ;-) Am I missing anything? Of course (1) and (2) could be combined into a single daemon. ATM the area is fraught with incompatibility. There are a ridiculous number of power management systems - one per architecture almost. Each has a different kernel-userspace interface. Every UPS has its own interface too (?) ;-) > There should be only one PM policy agent on the system. Why? As far as I see it, only some people need polling capabilities - i.e. those on battery or UPS. Why should they be subjected to the bloat etc. And those on battery might want multiple policies as Alan pointed out. [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Alan Cox <[EMAIL PROTECTED]> writes: [...] > I would tend to agree here. If you want to wire it to init the fine > but pm is basically message passing kernel->user and possibly > message reply to allow veto/approve. APM provides a good API for > this and there is a definite incentive to make ACPI use the same > messages, behaviour and extend it. I'm wondering if that veto business is really needed. Why not reject *all* APM rejectable events, and then let the userspace event handler send the system to sleep or turn it off? Anybody au fait with the APM spec? This would have the advantage that the veto stuff could be ripped out and things made simpler. -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Alan Cox <[EMAIL PROTECTED]> writes: > > I'm wondering if that veto business is really needed. Why not reject > > *all* APM rejectable events, and then let the userspace event handler > > send the system to sleep or turn it off? Anybody au fait with the APM > > spec? > > Because apmd is optional The veto stuff only comes into action, iff someone has registered as willing to exercise this power. We would not break compatibility with any std kernel by instead having a apmd send a "reject all" ioctl instead, and so deal with events without having the pressure of having to reject or accept them, and let us remove all the veto code from the kernel driver. Or am I missing something? -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: [...] > Fair enough. I don't think I would be out of line to say that our > resources are focused on enabling full ACPI functionality for Linux, > including a full-featured PM policy daemon. That said, I don't think > there's anything precluding the use of another daemon (or whatever) > from using the ACPI driver's interface. ACPI != PM. I don't see why ACPI details should be exposed to PM interface at all. [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Simon Richter <[EMAIL PROTECTED]> writes: [...] > Yes, that will be a separate daemon that will also get the > events. But I think it's a good idea to have a simple interface that > allows the user to run arbitrary commands when ACPI events occur, > even without acpid running (think of singleuser mode, embedded > systems, ...). The pmpolicy patch presents such a simple interface. An executable (the location of which is configurable) is run from the kernel with certain arguments. The advantages of this: (1) No nasty magic number binary interface, everything is text -> (2) Any sysadmin can easily write an event handler in sh, perl, or whatever scripting language, i.e. the userspace handler is much simpler. (3) No events, no bloat. (4) Kernel code is probably shorter (tho' less standard) than having a special device or procfs node. (5) Efficiency: the alternative is to have a program like APMD decoding the nasty binary interface and then spawning a shell script to deal with it. I myself am starting to dislike the idea: it was mostly motivated by the need to exercise a veto on APM events. This is in fact not necessary, if I understand correctly. An interface allowing multiple listeners is preferable. It remains to contact all the maintainers of the various PM and UPS systems to flesh out exactly what the interface should be capable of ;-) [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Alan Cox <[EMAIL PROTECTED]> writes: > > willing to exercise this power. We would not break compatibility > > with any std kernel by instead having a apmd send a "reject all" > > ioctl instead, and so deal with events without having the pressure > > of having to reject or accept them, and let us remove all the veto > > code from the kernel driver. Or am I missing something? > > That sounds workable. But the same program could reply to the events > just as well as issue the ioctl 8) Having more than one program holding the veto on each event is a bit of a hassle. Keeping track of "replies" is also a bit of a hassle. It'd be simpler to let userspace handle everything in line with e.g. the ACPI power button press, and suspend or turn off the machine in the normal manner. [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Avery Pennarun <[EMAIL PROTECTED]> writes: > On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote: > > > > willing to exercise this power. We would not break compatibility with > > > any std kernel by instead having a apmd send a "reject all" ioctl > > > instead, and so deal with events without having the pressure of having > > > to reject or accept them, and let us remove all the veto code from the > > > kernel driver. Or am I missing something? > > > > That sounds workable. But the same program could reply to the events just > > as well as issue the ioctl 8) > > AFAICT some APM BIOSes get impatient if you don't acknowledge/reject > the requests fast enough, and start to go bananas. By always > rejecting requests and then making user requests instead at some > time later, we might eliminate this problem (or just cause new > ones). Indeed. Neither proposal has however received wide testing as far as I know. The userspace ACCEPT/REJECT method was available as a patch from Stephen for a while though. > Also, I don't think the "critical suspend" message can be rejected > at all, so it would have to be a special case where currently I > don't think it's too bad. ATM it is a "special case" - we print a message if we try to reject a critical suspend. However the case is not so special that it requires more than a line or two ;-) I don't think there is any cause for concern on that front. [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: [...] > > ACPI != PM. I don't see why ACPI details should be exposed to PM > > interface at all. > > ACPI has by far the richest set of capabilities. It is a superset of > APM. Therefore a combined APM/ACPI interface is going to look a lot > like an ACPI interface. First, lets stop being so Intel/x86 centric ;-) There are more PM interfaces than APM/ACPI as Stephen Rothwell pointed out to me: more are already supported by the kernel. PPC has one, ARM has one, etc. And that's not even touching on UPSs and miscellaneous portable whatnots with their own special PM bits and pieces like IBM laptops. ACPI might be able to handle all that but it would require a very complex interface, if what I've seen of ACPI is anything to go by. Is this correct? A much simpler interface might not lose much functionality. > IMHO an abstracted interface at this point is overengineering. Maybe > later it will make sense, though. Each PM scheme has its own daemon and suspend/sleep tools at the moment. It makes sense to have just one daemon and toolset so that advanced functionality can be shared. Should the kernel present a common interface like HID, or should the daemon be able to understand all the various protocols (like gpm for mice)? -- http://www.penguinpowered.com/~vii - 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/
Next gen PM interface
John Fremlin <[EMAIL PROTECTED]> writes: [...] > IMHO the pm interface should be split up as following: Nobody has disagreed: therefore this separation must be perfect ;-) > (1) Battery status, power status, UPS status polling. It > should be possible for lots of processes to do this > simultaneously. [That does not prohibit a single process > querying the kernel and all the others querying it.] Solution. Have a bunch of procfs or dev nodes each giving info on a particular power source, like now, but vaguely standardise the output. > (2) Funky events happening to the physical machine, like a > button being pressed, the case being closed, etc. [Should this > include battery low warnings, power status changes? I don't > know.] Solution. Have a special procfs or dev node that any number of people can select(2) or read(2). Protocol text. Syntax: Where is one of the strings OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, is a space character, is a word signifying the kernel pm interface responsible for generating th event, is an arbitrary string. is a newline character \n. This is flexible and simple. It means a reasonable default behaviour can be suggested by the kernel (OFF,SLEEP,etc.) for events that userspace doesn't know about and yet userspace can choose fine grained policy and provide helpful error messages based on the exact event by checking the description. [...] > (3) Sending the machine to sleep, turning it off. It should be > possible to do this from userspace ;-) I would suggest that all pm capable objects should be able to be controlled individually. E.g. you should be able to send your monitor to sleep alone, leaving other stuff running. Fbdrivers are already capable of this on some archs. IOW I suggest a nice FS with a dir per PM capable device. In this dir would be name - descriptive text name of device class wake - writing to this node wakes device sleep - writing a number n (text encoded) sends the device to sleep in such a way that it can be back in action in no less than n seconds after a wakeup call on a vague guess basis. Reading from it gets errno. off - writing to this node puts device in deepest possible sleep, possibly losing state. Reading gets errno. Like the proc/sys/net/ipv4/neigh stuff you can have an all/ dir that'd try to whatever to everything. Hotunplug can be handled. Any objections? Would such a patch be accepted by the powers that be? [...] -- http://www.penguinpowered.com/~vii - 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: Next gen PM interface
Patrick Mochel <[EMAIL PROTECTED]> writes: > > > IMHO the pm interface should be split up as following: > > > > Nobody has disagreed: therefore this separation must be perfect ;-) > > I once heard that patience is a virtue. :) > > > > (1) Battery status, power status, UPS status polling. It > > > should be possible for lots of processes to do this > > > simultaneously. [That does not prohibit a single process > > > querying the kernel and all the others querying it.] > > > > Solution. Have a bunch of procfs or dev nodes each giving info on a > > particular power source, like now, but vaguely standardise the output. [...] > I can see at least two types of events - (forgive the lack of colorful > terminology) passive and active. Passive events are simply providing > status updates, much like the events described above. These are simply so > some UI can notify the user of things like a low battery or detection of > an AC adapter. These can be handled in much the same way as described > above. No they can't. They only happen once. Battery status exists all the time. [...] -- http://www.penguinpowered.com/~vii - 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: Next gen PM interface
Patrick Mochel <[EMAIL PROTECTED]> writes: [...] > > Solution. Have a special procfs or dev node that any number of people > > can select(2) or read(2). Protocol text. Syntax: > > > > > > > > Where is one of the strings > > OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, is a space character, > > is a word signifying the kernel pm interface responsible > > for generating th event, is an arbitrary string. is > > a newline character \n. > > > > This is flexible and simple. It means a reasonable default behaviour > > can be suggested by the kernel (OFF,SLEEP,etc.) for events that > > userspace doesn't know about and yet userspace can choose fine grained > > policy and provide helpful error messages based on the exact event by > > checking the description. > > First, Is there any reason why the kernel should do more text processing? Kernel does no text processing. Kernel merely gives text instead of magic numbers to the stream of bytes. > It is better left for user space. Besides, enumerated values > translated by userspace seems more efficient than copying and > parsing strings. Oh? Do you honestly believe there will be in any way a detectable difference? > Having a daemon that sits in user space and waits for system events > (denoted by enumerated values in some /proc or /dev file) seems simple > enough. Yes, but text strings are simpler. You don't have to export magic numbers in some kernel header (causing no end of woe). You can just cat /proc/pm/events to the console and understand it, and just about anybody with the rudiments of knowledge about programming in any language can write an event handler - even without having to know hardly anything about or look at the kernel source because the interface is so transparent and simple. > When it gets the request to power down, it handles calling init and > whatever else it wants to do. When it gets notification that the > laptop was plugged into the base station, it can look for new > devices and load the modules for them. Exactly. Right. Bang on target - but with text strings you can do it in a line or two of perl, and the kernel side is not made any more complex. > This can also handle the user-dictated policy, which I haven't seen > discussed yet. For instance, when you close the lid or press the power > button, the system can enter suspend or it can power off. If the kernel > simply exported the event, the userspace daemon could simply check its > config file for the proper thing to do and initiate the transition. Exactly what I was suggesting. In this case, you'd get the event SLEEP ACPI Laptop case closed and your perl script could do something vaguely like /ACPI Laptop case closed$/ && system "shutdown -p now"; to turn the machine off instead of sleeping. [...] > > sleep - writing a number n (text encoded) sends the device to > > sleep in such a way that it can be back in action in no less > > than n seconds after a wakeup call on a vague guess > > basis. Reading from it gets errno. Probably microseconds would be a more useful unit. > > off - writing to this node puts device in deepest possible > > sleep, possibly losing state. Reading gets errno. > > Sure, but does it really make sense for anything but system sleep > states? ACPI defines a mechnanism for runtime power management, > where devices will go into sleep states if they're not being > used. Given proper heuristics for controlling this, user-initiated > suspension of individual devices doesn't seem necessary. And, given > a proper abstraction in the PM layer, this should be extendable, to > some extent, to other low-level PM schemes. OK, so add another node, something like boredafter - writing a number of milliseconds tells device to go to some sort of sleep after that time has elapsed without activity. -- http://www.penguinpowered.com/~vii - 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: Next gen PM interface
Patrick Mochel <[EMAIL PROTECTED]> writes: [...] > > > I can see at least two types of events - (forgive the lack of colorful > > > terminology) passive and active. Passive events are simply providing > > > status updates, much like the events described above. These are simply so > > > some UI can notify the user of things like a low battery or detection of > > > an AC adapter. These can be handled in much the same way as described > > > above. > > > > No they can't. They only happen once. Battery status exists all the > > time. > > Yes they can. My point was they can be handled from userspace in the > same way that battery status does - by doing a select on a file in > /proc or /dev. Once in a while (or constantly) they get data from > the kernel - battery status, AC change, etc - that can be then > translated and displayed in the UI. I think these events have a generic utility not specific to UIs. In particular, when ones battery is running out, one would quite like the event manager to be notified. As is currently the case with e.g. apmd. Polling on battery charge left or battery voltage/current is different from this, surely? Why should such programs have to be notified that the battery was low? The event itself is pretty useless if you're doing polling but there is no point throwing it away, in case you aren't. [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Pavel Machek <[EMAIL PROTECTED]> writes: [...] > > I'm wondering if that veto business is really needed. Why not reject > > *all* APM rejectable events, and then let the userspace event handler > > send the system to sleep or turn it off? Anybody au fait with the APM > > spec? > > My thinkpad actually started blinking with some LED when you pressed > the button. LED went off when you rejected or when sleep was > completed. Does the led start blinking when the system sends an apm suspend? In that case I don't think you'd notice the brief period between the REJECT and the following suspend from userspace ;-) [...] -- http://www.penguinpowered.com/~vii - 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: Let init know user wants to shutdown
Jamie Lokier <[EMAIL PROTECTED]> writes: [...] > Are you sure? A suspend takes about 5-10 seconds on my laptop. You mean when you tell the apm driver from userspace to suspend? > (It was noticably faster with 2.3 kernels, btw. Now it spends a second > or two apparently not noticing the APM event (though the BIOS is making > the speaker beep), then syncing the disk, The BIOS got the event, problem is in BIOS surely? [...] -- http://www.penguinpowered.com/~vii - 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/
Changes to ide-cd for 2.4.1 are broken?
Specifically, this part:
@@ -2324,11 +2309,17 @@
sense.ascq == 0x04)
return CDS_DISC_OK;
+
+ /*
+* If not using Mt Fuji extended media tray reports,
+* just return TRAY_OPEN since ATAPI doesn't provide
+* any other way to detect this...
+*/
if (sense.sense_key == NOT_READY) {
- /* ATAPI doesn't have anything that can help
- us decide whether the drive is really
- emtpy or the tray is just open. irk. */
- return CDS_TRAY_OPEN;
+ if (sense.asc == 0x3a && (!sense.ascq||sense.ascq == 1))
+ return CDS_NO_DISC;
+ else
+ return CDS_TRAY_OPEN;
}
My tray is open as I type, and it is misreported as CDS_NO_DISC. In
2.4.0 it worked fine.
# strace cdd
execve("/trusted/bin/cdd", ["cdd"], [/* 35 vars */]) = 0
open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = 5
ioctl(5, CDROM_DRIVE_STATUS, 0) = 1
write(1, "No disc in drive\n", 17No disc in drive
) = 17
_exit(0)= ?
>From linux/include/linux/cdrom.h:
#define CDS_NO_INFO 0 /* if not implemented */
#define CDS_NO_DISC 1
#define CDS_TRAY_OPEN 2
#define CDS_DRIVE_NOT_READY 3
#define CDS_DISC_OK 4
(The usual plug: download my beautifully minimalistic but featureful
hand coded assembly cd player from
http://john.snoop.dk/programs/linux/asm-toys).
Some miscellaneous hardware details from dmesg:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
PCI: Hardcoded IRQ 14 for device 00:0f.0
ALI15X3: chipset revision 32
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: SAMSUNG VG36483A (6.48GB), ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: IBM-DTLA-305020, ATA DISK drive
hdd: TOSHIBA DVD-ROM SD-M1102, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 12685680 sectors (6495 MB) w/494KiB Cache, CHS=789/255/63, (U)DMA
hdc: 40188960 sectors (20577 MB) w/380KiB Cache, CHS=39870/16/63, (U)DMA
hdd: ATAPI 24X DVD-ROM drive, 256kB Cache
Uniform CD-ROM driver Revision: 3.12
--
http://www.penguinpowered.com/~vii
-
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: Changes to ide-cd for 2.4.1 are broken?
Jens Axboe <[EMAIL PROTECTED]> writes:
[...]
> > You know all about this stuff, so probably I am mistaken.
> > However, my copy of SFF8020-r2.6 everywhere has
> > "Sense 02 ASC 3A: Medium not present" without giving
> > subcodes to distinguish Tray Open from No Disc.
> > So, it seems to me that drives built to this spec will not have
> > nonzero ASCQ.
>
> Right, old ATAPI has 3a/02 as the only possible condition, so we
> can't really tell between no disc and tray open. I guess the safest
> is to just keep the old behaviour for !ascq and report open.
Jens, you are maintainer? Could you ask Linus or Alan to revert the
change below?
diff -u --recursive --new-file v2.4.0/linux/drivers/ide/ide-cd.c
linux/drivers/ide/ide-cd.c
--- v2.4.0/linux/drivers/ide/ide-cd.c Tue Jan 2 16:59:17 2001
+++ linux/drivers/ide/ide-cd.c Sun Jan 28 13:37:50 2001
@@ -2324,11 +2309,17 @@
sense.ascq == 0x04)
return CDS_DISC_OK;
+
+ /*
+* If not using Mt Fuji extended media tray reports,
+* just return TRAY_OPEN since ATAPI doesn't provide
+* any other way to detect this...
+*/
if (sense.sense_key == NOT_READY) {
- /* ATAPI doesn't have anything that can help
- us decide whether the drive is really
- emtpy or the tray is just open. irk. */
- return CDS_TRAY_OPEN;
+ if (sense.asc == 0x3a && (!sense.ascq||sense.ascq == 1))+
+ return CDS_NO_DISC;
+ else
+ return CDS_TRAY_OPEN;
}
--
http://www.penguinpowered.com/~vii
-
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: APM suspend system lockup under 2.4.2 and 2.4.2ac1
Unfortunately, the APM maintainer, Stephen Rothwell, seems to have gone into hibernation (pun) and is not responding to emails. bradley mclain <[EMAIL PROTECTED]> writes: > apm --suspend causes my system to hang under 2.4.2 and 2.4.2ac1. it > was working fine under 2.4.1ac19. looking at syslog it appears that > the driver for my xircom pcmcia card may be involved -- it was the > last entry on two of three occasions. the latest lockup (under > 2.4.1ac1) left no trace in syslog. Are all kernel messages dumped to syslog? See syslog.conf(5). > upon issuing the command the screen shuts down, but the rest of the > machine (drive, etc.) fails to, and i cannot get control back. If the screen shutdown, all the PM enabled drivers OK'd the suspend and the APM state was changed. Perhaps the particular driver you used bungled things somehow. You could try again with the driver/card unloaded, which would help narrow the cause of the problem down. [...] -- http://www.penguinpowered.com/~vii - 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: Changes to ide-cd for 2.4.1 are broken?
"Michael Johnson" <[EMAIL PROTECTED]> writes: > >> You know all about this stuff, so probably I am mistaken. > >> However, my copy of SFF8020-r2.6 everywhere has > >> "Sense 02 ASC 3A: Medium not present" without giving > >> subcodes to distinguish Tray Open from No Disc. > >> So, it seems to me that drives built to this spec will not have > >> nonzero ASCQ. > > > >Right, old ATAPI has 3a/02 as the only possible condition, so we > >can't really tell between no disc and tray open. I guess the safest > >is to just keep the old behaviour for !ascq and report open. > I don't understand why the current(2.4.1) behavior is a problem... It isn't a problem, it just changed in the middle of a stable release. [...] -- http://www.penguinpowered.com/~vii - 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: APM suspend system lockup under 2.4.2 and 2.4.2ac1
Alan Cox <[EMAIL PROTECTED]> writes: > > the sound card is a yamaha YMF-744B. i hadn't been > > compiling with sound support (i dont care about sound > > on my laptop), but when i got 2.4.2 i decided to try, > > and now i'm pretty sure that was the problem. > > The Yamaha sound driver doesnt handle the case where the bios fails > to restore the chip status and expects a windows driver to do its > dirty work. That requires on resume that the device is completely > reloaded. > > A workaround is to make it a module, unload it before suspend and > reload it after resume but thats pretty umm uggly. Why not use kernel/pm.c:pm_register? Then you can either refuse suspend or have a proper workaround. -- http://www.penguinpowered.com/~vii - 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: APM suspend system lockup under 2.4.2 and 2.4.2ac1
Alan Cox <[EMAIL PROTECTED]> writes: > > Why not use kernel/pm.c:pm_register? Then you can either refuse > > suspend or have a proper workaround. > > Feel free to provide code. You have me there - I should have realised who I was writing to ;-) [...] > I dont have the hardware I neither. -- http://www.penguinpowered.com/~vii - 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: Broken APM Support since 2.4.1-ac1
Boris Dragovic <[EMAIL PROTECTED]> writes: > i have compaq presario 1245 and kernel 2.4.2 does not do power off on > shutdown although all necessary kernel options are compiled in.. Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He loves feedback. [...] -- http://www.penguinpowered.com/~vii - 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: Broken APM Support since 2.4.1-ac1
Daniel Stutz <[EMAIL PROTECTED]> writes: > APM support for Lifebook C 6185 is broken since 2.4.1-ac1. > While trying to go in suspend mode the system hangs. Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He likes feedback. [...] -- http://www.penguinpowered.com/~vii - 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: APM, virtual console problem in 2.4.0
Joseph Pingenot <[EMAIL PROTECTED]> writes: > When suspending my laptop (Toshiba Satellite 1605CDS; BIOS set to > suspend to disk) with Debian 2.2r2's 'apm -s', the screen blanks and > then the system locks up hard (not even the power button works). In Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He loves feedback. [...] -- http://www.penguinpowered.com/~vii - 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/
Unified power management userspace policy
Hi all!
At the moment there are two power management drivers in the linux
kernel (AFAIK). They each have different userspace interfaces --
/proc/apm and /dev/apmctl and /proc/sys/acpi/events or something. This
is not altogether bad, but as they do the same thing, it might be nice
to unify (part) of the interface. In fact this is already done for the
in kernel interface with pm_send_all.
The kernel patch below extends the pm_send_all idea to ask userspace
if the event causing it should be allowed to go ahead or not. This
functionality is useful to me, because my power button sends an APM
user suspend to the kernel, which I wish to convert into a clean
shutdown -p now. The functionality is only hooked up to the APM driver
at the moment (because that was the only caller of pm_send_all that I
could find and ACPI doesn't seem to do anything useful on my box).
The kernel will run /sbin/powermanager (proc configurable) when it
receives a rejectable PM event. This is to my mind preferable to
having a power daemon because a PM event might occur even when the
daemon isn't started yet, you waste a process entry the whole time,
I'd have to implement a bunch of special file ops and binary
interfaces, and to parallel the hotplug system.
There is an APM specific patch floating around that would permit apmd
to reject suspend events. I played around with it for a bit updating
it to the late 2.4.0-test12 but I didn't like it because it did
suspend() directly after receiving the event from the BIOS, so my box
would suspend briefly before rejecting the event.
An example /sbin/powermanager should be being uploaded to my homepage
as I write:
http://www.penguinpowered.com/~vii/programs/linux/offbutton
or
http://john.snoop.dk/programs/linux/offbutton
The patch has been working fine for me in various forms since
2.4.0-prerelease came out, though I'm hardly a power user (pun).
It is against linux 2.4.0.
diff -u --recursive linux-clean/arch/i386/kernel/apm.c linux-hacked-pmpolicy/arch/i386/kernel/apm.c
--- linux-clean/arch/i386/kernel/apm.c Sat Dec 30 00:21:33 2000
+++ linux-hacked-pmpolicy/arch/i386/kernel/apm.c Mon Jan 8 21:15:23 2001
@@ -148,6 +148,8 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * --- Modified to support new pm_event API (John Fremlin
+ * <[EMAIL PROTECTED]>)
*
* APM 1.1 Reference:
*
@@ -884,30 +886,65 @@
#endif
}
+static int soft_suspend()
+{
+ struct pm_event pe;
+ memset(&pe,0,sizeof pe);
+
+ pe.pe_state = PM_STATE_SLEEP;
+ pe.pe_source = PME_SRC_SOFT;
+ pe.pe_flags = PME_FLAGS_REJECTABLE;
+
+ return pm_request_event(&pe);
+}
+
static int send_event(apm_event_t event)
{
+ struct pm_event pe;
+ memset(&pe,0,sizeof pe);
+
switch (event) {
case APM_SYS_SUSPEND:
+ pe.pe_state = PM_STATE_SLEEP;
+ pe.pe_source = PME_SRC_SYS;
+ pe.pe_flags = PME_FLAGS_REJECTABLE;
+ break;
+
case APM_CRITICAL_SUSPEND:
+ pe.pe_state = PM_STATE_SLEEP;
+ pe.pe_source = PME_SRC_SYS;
+ break;
+
case APM_USER_SUSPEND:
- /* map all suspends to ACPI D3 */
- if (pm_send_all(PM_SUSPEND, (void *)3)) {
- if (event == APM_CRITICAL_SUSPEND) {
-printk(KERN_CRIT "apm: Critical suspend was vetoed, expect armageddon\n" );
-return 0;
- }
- if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- return 0;
- }
+ pe.pe_state = PM_STATE_SLEEP;
+ pe.pe_source = PME_SRC_HWUSER;
+ pe.pe_flags = PME_FLAGS_REJECTABLE;
break;
- case APM_NORMAL_RESUME:
+
case APM_CRITICAL_RESUME:
- /* map all resumes to ACPI D0 */
- (void) pm_send_all(PM_RESUME, (void *)0);
+ pe.pe_state = PM_STATE_WAKEFUL;
+ pe.pe_source = PME_SRC_SYS;
+ break;
+
+ case APM_NORMAL_RESUME:
+ pe.pe_state = PM_STATE_WAKEFUL;
+ pe.pe_source = PME_SRC_HWUSER;
break;
+
+ default:
+ return 1;
}
+ if(pm_prepare_for_event(&pe))
+ {
+ if (event == APM_CRITICAL_SUSPEND) {
+ printk(KERN_CRIT "apm: critical suspend was vetoed, expect armageddon\n" );
+ return 0;
+ }
+ if (apm_info.connection_version > 0x100)
+ apm_set_power_state(APM_STATE_REJECT);
+ return 0;
+ }
return 1;
}
@@ -925,8 +962,10 @@
err = APM_SUCCESS;
if (err != APM_SUCCESS)
apm_error("suspend", err);
- send_event(APM_NORMAL_RESUME);
sti();
+ /* We mustn't pm_event_lock because whoever is waiting for the
+ * end of this suspend is holding the lock */
+ send_event(APM_NORMAL_RESUME);
queue_event(APM_NORMAL_RESUME, NULL);
for (as = user_list; as != NULL; as = as->next) {
as->suspend_wait = 0;
@@ -947,6 +986,21 @@
apm_error("standby", err);
}
+static int apm_enter_state(pm_state_t*ps)
+{
+ switch(*ps){
+ case PM_STATE_SLEEP:
+ return suspend();
+ case PM_STATE_WAKEFUL:
+ return 0;
+ case PM_STATE_POWEROFF:
Re: Unified power management userspace policy
Hi! Andrew Morton <[EMAIL PROTECTED]> writes: > Could you please use call_usermodehelper() in this patch > rather than exec_usermodehelper()? I want to kill > exec_usermodehelper() sometime. The reason I used exec_usermodehelper is that I wanted to waitpid on the process to see how it exited. Am I still allowed to do that if it runs as a child of keventd? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-x features ?
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> > 1) top (procps-2.0.7) gives me the messages :
> > 'bad data in /proc/uptime'
> > 'bad data in /proc/loadavg'
> > cat /proc/uptime
> > 1435.30 904.74
> > cat /proc/loadavg
> > 0.01 0.21 0.29 1/17 19444
> > What is wrong ?
You probably have locale settings where the decimal point is a comma
so scanf on /proc/loadavg etc. doesn't work. The following patch
(submitted to RedHat ages ago) fixes that for me.
diff -u --recursive procps-2.0.7-orig/proc/sysinfo.c procps-2.0.7-hacked/proc/sysinfo.c
--- procps-2.0.7-orig/proc/sysinfo.c Mon Jul 10 20:36:13 2000
+++ procps-2.0.7-hacked/proc/sysinfo.c Wed Nov 29 23:11:41 2000
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -62,12 +64,19 @@
/***/
int uptime(double *uptime_secs, double *idle_secs) {
double up=0, idle=0;
+char*numeric=setlocale(LC_NUMERIC,0);
+/* It is necessary to save and restore the numeric locale, because
+if the locale we're in happens to use , instead of decimal point,
+we can't sscanf the values in /proc/uptime */
+setlocale(LC_NUMERIC,"C");
FILE_TO_BUF(UPTIME_FILE,uptime_fd);
if (sscanf(buf, "%lf %lf", &up, &idle) < 2) {
fprintf(stderr, "bad data in " UPTIME_FILE "\n");
return 0;
}
+setlocale(LC_NUMERIC,numeric);
+
SET_IF_DESIRED(uptime_secs, up);
SET_IF_DESIRED(idle_secs, idle);
return up; /* assume never be zero seconds in practice */
@@ -171,12 +180,20 @@
/***/
int loadavg(double *av1, double *av5, double *av15) {
double avg_1=0, avg_5=0, avg_15=0;
+/* It is necessary to save and restore the numeric locale, because
+if the locale we're in happens to use , instead of decimal point,
+we can't sscanf the values in /proc/loadavg */
+char*numeric=setlocale(LC_NUMERIC,0);
+setlocale(LC_NUMERIC,"C");
FILE_TO_BUF(LOADAVG_FILE,loadavg_fd);
if (sscanf(buf, "%lf %lf %lf", &avg_1, &avg_5, &avg_15) < 3) {
fprintf(stderr, "bad data in " LOADAVG_FILE "\n");
exit(1);
+
}
+setlocale(LC_NUMERIC,numeric);
+
SET_IF_DESIRED(av1, avg_1);
SET_IF_DESIRED(av5, avg_5);
SET_IF_DESIRED(av15, avg_15);
[...]
--
http://www.penguinpowered.com/~vii
[PATCH] include/linux/rtc.h tiny typo
Against 2.4.0. --- linux/include/linux/rtc.h~ Tue Jul 11 19:18:53 2000 +++ linux/include/linux/rtc.h Sun Jan 21 16:06:53 2001 @@ -6,7 +6,7 @@ * Copyright (C) 1999 Hewlett-Packard Co. * Copyright (C) 1999 Stephane Eranian <[EMAIL PROTECTED]> */ -#ifndef _LINUX_RTC_H +#ifndef _LINUX_RTC_H_ #define _LINUX_RTC_H_ /* -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] linux-2.4.1-pre9/include/linux/acpi.h broke acpid compilation
"Adam J. Richter" <[EMAIL PROTECTED]> writes: > linux-2.4.1-pre9/include/linux/acpi.h contains declares the routine > acpi_get_rsdp_ptr returning the kernel-only type "u64", without > bracketing the declaration in "#ifdef __KERNEL__...#endif". > Consequently, a user level program that attempts to include > , such as acpid, gets a compilation error. The > following patch fix the problem by stretching an earlier "#ifdef > __KERNEL__...#endif" area to cover the acpi_get_rsdp_ptr > declaration. I sent a similar patch to the maintainer [EMAIL PROTECTED] on December 29 but have received no response so far. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ISA PnP for Yamaha OPL3-SAx sound driver
Support for this card is currently broken for people whose BIOS used
to activate it with ISA PnP, as the kernel now decides to deactivate
it. On 27 Oct 2000 21:48:44 +0100, I sent the maintainer
<[EMAIL PROTECTED]> and the mailing list
<[EMAIL PROTECTED]> this patch, but I didn't get any
replies. Other people have written (no doubt better) patches to
accomplish the same thing, but somehow none have appeared in the Linus
tree.
This patch implements ISA PnP probe and activate/deactivate for the
OPL3-SAx. As I don't have the specs for this card, I only know that it
works for me; nevertheless, it should not break any configurations as
the PnP probe only kicks in if the resource parameters are not given
as module arguments.
It should now be possible to compile the driver directly into the
kernel.
The patch is against 2.4.0-test10-pre6, but still applies cleanly to
test12-pre3.
--- linux-orig/drivers/sound/opl3sa2.c Fri Aug 11 16:26:43 2000
+++ linux/drivers/sound/opl3sa2.c Fri Oct 27 21:27:16 2000
@@ -33,13 +33,15 @@
* (with thanks to Ben Hutchings for the heuristic),
* removed now unnecessary force option. (Jan 5, 1999)
* Christoph Hellwig Adapted to module_init/module_exit (Mar 4, 2000)
- *
+ * John FremlinDo ISA PnP (Oct 27, 2000)
*/
#include
#include
#include
+#include
+
#include "sound_config.h"
#include "ad1848.h"
@@ -92,6 +94,10 @@
unsigned int treble;
} opl3sa2_mixerdata;
+#if defined CONFIG_ISAPNP || defined CONFIG_ISAPNP_MODULE
+static struct pci_dev *pnp_dev;
+#endif
+
#ifdef CONFIG_OPL3SA2_CTRL_BASE
/* Set control port if compiled into the kernel */
static opl3sa2_mixerdata opl3sa2_data = { CONFIG_OPL3SA2_CTRL_BASE, };
@@ -517,11 +523,63 @@
}
+static inline void opl3sa2_pnp_deactivate()
+{
+#if defined CONFIG_ISAPNP || defined CONFIG_ISAPNP_MODULE
+ if(pnp_dev){
+ pnp_dev->deactivate(pnp_dev);
+ pnp_dev=0;
+ }
+#endif
+}
+
+
+static inline int opl3sa2_pnp_activate(struct address_info *sa2_cfg,
+ struct address_info *mss_cfg,
+ struct address_info *mpu_cfg)
+{
+#if defined CONFIG_ISAPNP || defined CONFIG_ISAPNP_MODULE
+ int ret;
+
+ opl3sa2_pnp_deactivate();
+
+ pnp_dev = isapnp_find_dev(NULL,
+ ISAPNP_VENDOR('Y','M','H'),
+ ISAPNP_FUNCTION(0x0021),
+ NULL);
+ if (!pnp_dev)
+ return -ENODEV;
+ if (pnp_dev->active)
+ return -EBUSY;
+ if (pnp_dev->prepare(pnp_dev)<0)
+ return -EAGAIN;
+ if ((ret = pnp_dev->activate(pnp_dev))) {
+ if(ret == -EBUSY){
+ /*already activated*/
+ } else {
+ printk(KERN_ERR "opl3sa2: isapnp configure failed (out of
+resources?)\n");
+ return -ENOMEM;
+ }
+ }
+
+ sa2_cfg->io_base = pnp_dev->resource[0].start;
+ mss_cfg->io_base = pnp_dev->resource[1].start;
+ /* pnp_dev->resource[2].start is for OPL3 FM*/
+ mpu_cfg->io_base = pnp_dev->resource[3].start;
+
+ mss_cfg->irq = sa2_cfg->irq = pnp_dev->irq_resource[0].start;
+ mss_cfg->dma = sa2_cfg->dma = pnp_dev->dma_resource[0].start;
+ mss_cfg->dma2 = sa2_cfg->dma2 = pnp_dev->dma_resource[1].start;
+#endif /* defined CONFIG_ISAPNP || defined CONFIG_ISAPNP_MODULE*/
+ return 0;
+}
+
+
static int __init probe_opl3sa2(struct address_info *hw_config)
{
unsigned char version = 0;
char tag;
-
+
/*
* Verify that the I/O port range is free.
*/
@@ -605,6 +663,7 @@
{
/* Release control ports */
release_region(hw_config->io_base, 2);
+ opl3sa2_pnp_deactivate();
/* Unload mixer */
if(opl3sa2_mixer >= 0)
@@ -671,8 +730,8 @@
cfg_mpu.always_detect = 1; /* It's there, so use shared IRQs */
if(cfg.io_base == -1 || cfg.irq == -1 || cfg.dma == -1 || cfg.dma2 == -1 ||
cfg2.io_base == -1) {
- printk(KERN_ERR "opl3sa2: io, mss_io, irq, dma, and dma2 must be
set.\n");
- return -EINVAL;
+ if(opl3sa2_pnp_activate(&cfg,&cfg2,&cfg_mpu)) /* Have a bash at PnP */
+ return -EINVAL;
}
/* Call me paranoid: */
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
Steven Cole <[EMAIL PROTECTED]> writes: [...] > In each case, the task and the tools used are the same. The only > difference was the kernel used. In both cases, 2.2.18 won by 3%. > Its comparing apples to apples and oranges to oranges. Granted 3% > isn't very much, but I would have guessed that 2.4.0 would have been > the winner. It wasn't, at least for this single processor machine. Two points: (1) gcc 2.95 makes slightly slower code than egcs-1.1 (according to benchmarks on gcc.gnu.org) so compile 2.4 kernel with egcs for a fairer comparison. (2) The new VM was a performance regression for throughput. I think that it is important that the extent of the indisputable performance decreases be quantified and traced. For me there was a subjective performance peak around 2.3.48 IIRC, though it might have been before. Andrea Archangeli has a VM patch that seems to help in some cases. It would be interesting to run a series of (automated) tests on a lot of kernel versions, and to see how far performance is behind FreeBSD (or even NetBSD). [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: DPMS kicks in at the wrong time
John Summerfield <[EMAIL PROTECTED]> writes: [...] > 3) When I then switch back to a virtual console, the screen blanks > and switches to power-saving mode. Which powersave mode? There are three, IIRC. You can tell them apart by the color of or whether the light blinks on some monitors. If the monitor is set to a modeline that it knows is crazy it might turn itself off automatically instead of trying to display it. That is, the framebuffer driver or XFree86 is probably not reseting some values it should. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: Kernel panics on sending large ping packets using 'ping'
Jogchem de Groot <[EMAIL PROTECTED]> writes: [...] > 1: Kernel panics on sending large ping packets using 'ping' Not for me. [...] > 4: Linux version 2.4.0-test12 Linux 2.4.0-test13-pre4-tosatti [...] > 6: #!/bin/sh > ping -s 6 127.0.0.1 Ping from netkit-combo-0.17: # ping -s 6 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 6 octets data 60008 octets from 127.0.0.1: icmp_seq=0 ttl=255 time=5.6 ms 60008 octets from 127.0.0.1: icmp_seq=1 ttl=255 time=4.8 ms 60008 octets from 127.0.0.1: icmp_seq=2 ttl=255 time=4.8 ms [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Why was this APM patch not fully applied?
On Tue Apr 04 2000 - 23:19:12 EDT, Stephen Rothwell posted a patch to linux-kernel. See http://boudicca.tux.org/hypermail/linux-kernel/2000week15/0481.html To quote: This patch (against 2.3.99pre4-4) does the following: Allow user mode programs to reject standby and suspend operations. [...] This first item is important to me. Unfortunately, the patch no longer applies to current kernels (test13-pre4). Was there any reason for it not to be included, or was it just ignored accidently? (The patch is still available at http://linuxcare.com.au/apm/ if anyone cares.) -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add capability to reject APM suspend events from userspace
This patch makes it possible to use the off button to cleanly shutdown
a computer. The feature has been supported by the userspace apmd
daemon for ages, but for some reason the patches to include it in the
kernel were (apparently) ignored by Linus' patch tracking "system".
For the original patch by the person in charge of APM, Stephen
Rothwell, see:
http://boudicca.tux.org/hypermail/linux-kernel/2000week15/0481.html
The following patch is based on the above, but only adds functionality
to reject a suspend event, and does not integrate the other useful
features. On the other hand, it does apply to linux-2.4.0-test13-pre4
so people can use it now.
diff -u linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c
linux-hacked/arch/i386/kernel/apm.c
--- linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c Fri Dec 29 22:47:16 2000
+++ linux-hacked/arch/i386/kernel/apm.c Fri Dec 29 22:49:32 2000
@@ -38,6 +38,7 @@
* Jan 2000, Version 1.12
* Feb 2000, Version 1.13
* Nov 2000, Version 1.14
+ * Dec 2000, Version 1.15
*
* History:
*0.6b: first version in official kernel, Linux 1.3.46
@@ -148,6 +149,10 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Add APM_IOC_REJECT ioctl, based on a patch from Stephen
+ * Rothwell but apparently written by Craig Markwardt
+ * <[EMAIL PROTECTED]>.
+ * John Fremlin <[EMAIL PROTECTED]>
*
* APM 1.1 Reference:
*
@@ -301,6 +306,7 @@
int suspend_result;
int suspends_pending;
int standbys_pending;
+ int rejects_pending;
int suspends_read;
int standbys_read;
int event_head;
@@ -325,6 +331,7 @@
#endif
static int suspends_pending;
static int standbys_pending;
+static int rejects_pending;
static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -350,7 +357,7 @@
static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
static struct apm_user * user_list;
-static chardriver_version[] = "1.14"; /* no spaces */
+static chardriver_version[] = "1.15"; /* no spaces */
static char * apm_event_name[] = {
"system standby",
@@ -832,6 +839,15 @@
as->standbys_pending++;
standbys_pending++;
break;
+
+ case APM_SUSPEND_REJECT:
+ as->suspend_wait = 0;
+ as->suspend_result = -EAGAIN;
+ /* Fall through to */
+ case APM_STANDBY_REJECT:
+ as->rejects_pending++;
+ rejects_pending++;
+ break;
}
}
wake_up_interruptible(&apm_waitqueue);
@@ -1211,6 +1227,41 @@
return 0;
}
+static int send_reject(struct apm_user *as, apm_event_t state)
+{
+ if (as->rejects_pending > 0) {
+ as->rejects_pending--;
+ rejects_pending--;
+ } else {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ queue_event(APM_SUSPEND_REJECT, as);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ queue_event(APM_STANDBY_REJECT, as);
+ break;
+ }
+ }
+ if ((rejects_pending <= 0) &&
+ (suspends_pending <= 0) &&
+ (standbys_pending <= 0)) {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ send_event(APM_NORMAL_RESUME);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ send_event(APM_STANDBY_RESUME);
+ break;
+ }
+ return apm_set_power_state(APM_STATE_REJECT);
+ }
+ return APM_SUCCESS;
+}
+
static int do_ioctl(struct inode * inode, struct file *filp,
u_int cmd, u_long arg)
{
@@ -1262,12 +1313,30 @@
return as->suspend_result;
}
break;
+ case APM_IOC_REJECT:
+ if (as->suspends_read > 0) {
+ as->suspends_read--;
+ as->suspends_pending--;
+ suspends_pending--;
+ if(send_reject(as, APM_SYS_SUSPEND)!=APM_SUCCESS)
+
Re: Forcible removal of modules
Thomas Hood <[EMAIL PROTECTED]> writes: > Sometimes modules need to be reloaded in order > to cause some sort of reinitialization (of the > driver or of the hardware) to occur. Why not set up the device driver to handle PM events itself. See Documentation/pm.txt under Driver Interface. I have a race free version of pm_send_all if you want it. [...] -- http://www.penguinpowered.com/~vii - 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/
Racing power management
Jeff Garzik <[EMAIL PROTECTED]> writes: > John Fremlin wrote: > > Why not set up the device driver to handle PM events itself. See > > Documentation/pm.txt under Driver Interface. > > For PCI drivers, you implement the ::suspend and ::remove hooks. > > > I have a race free version of pm_send_all if you want it. > > Is this the same thing that is in 2.4.3-pre3? Aarrgh. Looks like Alan Cox got his version in kernel first. (I did write mine before.) If I am not mistaken there is one (hypothetical) race still remaining in Alan's version. Last time I checked the only code doing pm_send_all was in the i386 APM driver (and so of course there is no chance of any race at all even with the old version, if I understand correctly). But suppose there were another pm_send_all caller. APM would decide to user suspend and call pm_send_all asking for a SUSPEND to check it was allowed to. While this is happening some clueless loser decides to pm_send_all RESUME for whatever reason. This loser has to wait until the APM pm_send_all finishes, but hypothetically and if I am not mistaken, his pm_send_all RESUME could get in just after the APM pm_send_all finished and just before APM made the physical BIOS call to suspend the machine. This would screw stuff up of course. You may say, this is rather improbable if not impossible, but it does suggest that it would be a good idea to have locking wrapping pm_send_all and the hardware machine suspend request. Cue: John's pmpolicy patch. Unfortunately, my patch adds another thing as well: /sbin/powermanager so it got (is getting) trampled on by a lot of people who didn't like that idea. If anybody wants the race free PM by itself, I can factor out that bit. -- http://www.penguinpowered.com/~vii - 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: kernel apm code
David Balazic <[EMAIL PROTECTED]> writes:
> The newer version has among other things support for
> the APM_IOC_REJECT ioctl which is useful for example
> when implementing "run /sbin/shutdown -h when the power
> button is pressed".
>
> While isn't this merged into the official kernel ?
The maintainer hasn't the time to do it. He promised me he would in
February, when I telephone, but hasn't bothered to do anything
AFAICS. I hacked together the following patch for it a while ago,
which updated APM_IOC_REJECT for slightly more recent kernels (be
warned, I think I made some mistakes)
diff -u linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c linux-hacked/arch/i386/kernel/apm.c
--- linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c Fri Dec 29 22:47:16 2000
+++ linux-hacked/arch/i386/kernel/apm.c Fri Dec 29 22:49:32 2000
@@ -38,6 +38,7 @@
* Jan 2000, Version 1.12
* Feb 2000, Version 1.13
* Nov 2000, Version 1.14
+ * Dec 2000, Version 1.15
*
* History:
*0.6b: first version in official kernel, Linux 1.3.46
@@ -148,6 +149,10 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Add APM_IOC_REJECT ioctl, based on a patch from Stephen
+ * Rothwell but apparently written by Craig Markwardt
+ * <[EMAIL PROTECTED]>.
+ * John Fremlin <[EMAIL PROTECTED]>
*
* APM 1.1 Reference:
*
@@ -301,6 +306,7 @@
int suspend_result;
int suspends_pending;
int standbys_pending;
+ int rejects_pending;
int suspends_read;
int standbys_read;
int event_head;
@@ -325,6 +331,7 @@
#endif
static int suspends_pending;
static int standbys_pending;
+static int rejects_pending;
static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -350,7 +357,7 @@
static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
static struct apm_user * user_list;
-static char driver_version[] = "1.14"; /* no spaces */
+static char driver_version[] = "1.15"; /* no spaces */
static char * apm_event_name[] = {
"system standby",
@@ -832,6 +839,15 @@
as->standbys_pending++;
standbys_pending++;
break;
+
+ case APM_SUSPEND_REJECT:
+ as->suspend_wait = 0;
+ as->suspend_result = -EAGAIN;
+ /* Fall through to */
+ case APM_STANDBY_REJECT:
+ as->rejects_pending++;
+ rejects_pending++;
+ break;
}
}
wake_up_interruptible(&apm_waitqueue);
@@ -1211,6 +1227,41 @@
return 0;
}
+static int send_reject(struct apm_user *as, apm_event_t state)
+{
+ if (as->rejects_pending > 0) {
+ as->rejects_pending--;
+ rejects_pending--;
+ } else {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ queue_event(APM_SUSPEND_REJECT, as);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ queue_event(APM_STANDBY_REJECT, as);
+ break;
+ }
+ }
+ if ((rejects_pending <= 0) &&
+ (suspends_pending <= 0) &&
+ (standbys_pending <= 0)) {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ send_event(APM_NORMAL_RESUME);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ send_event(APM_STANDBY_RESUME);
+ break;
+ }
+ return apm_set_power_state(APM_STATE_REJECT);
+ }
+ return APM_SUCCESS;
+}
+
static int do_ioctl(struct inode * inode, struct file *filp,
u_int cmd, u_long arg)
{
@@ -1262,12 +1313,30 @@
return as->suspend_result;
}
break;
+ case APM_IOC_REJECT:
+ if (as->suspends_read > 0) {
+ as->suspends_read--;
+ as->suspends_pending--;
+ suspends_pending--;
+ if(send_reject(as, APM_SYS_SUSPEND)!=APM_SUCCESS)
+return -EREMOTEIO;
+ } else if (as->standbys_read > 0) {
+ as->standbys_read--;
+ as->standbys_pending--;
+ standbys_pending--;
+ if(send_reject(as, APM_SYS_STANDBY)!=APM_SUCCESS)
+return -EREMOTEIO;
+ } else
+ return -EINVAL;
+ break;
default:
return -EINVAL;
}
return 0;
}
+
+
static int do_release(struct inode * inode, struct file * filp)
{
struct apm_user * as;
@@ -1277,14 +1346,16 @@
return 0;
filp->private_data = NULL;
lock_kernel();
+ rejects_pending -= as->rejects_pending;
+ as->rejects_pending = 0;
if (as->standbys_pending > 0) {
standbys_pending -= as->standbys_pending;
- if (standbys_pending <= 0)
+ if (standbys_pending <= 0 && rejects_pending <= 0)
standby();
}
if (as->suspends_pending > 0) {
suspends_pending -= as->suspends_pending;
- if (suspends_pending <= 0)
+ if (suspends_pending <= 0 && rejects_pending <= 0)
(void) suspend();
}
if (user_list == as)
@@ -1318,7 +1389,7 @@
}
as->magic = APM_BIOS_MAGIC;
as->event_tail = as->event_head
Re: kernel apm code
David Balazic <[EMAIL PROTECTED]> writes: > John Fremlin wrote: > > > > David Balazic <[EMAIL PROTECTED]> writes: [...] > > The maintainer hasn't the time to do it. He promised me he would in > > February, when I telephone, but hasn't bothered to do anything > > AFAICS. I hacked together the following patch for it a while ago, > > which updated APM_IOC_REJECT for slightly more recent kernels (be > > warned, I think I made some mistakes) > > It uses the same version number ( 1.15 ) as the "official" apm.c ( > at linuxcare.com.au/apm ). I don't think that is a good idea. Maybe > 1.14b ? Well it's not going to go anywhere unless you want to look after it so there's not much point in worrying about that :-) [...] > > I made a (IMHO) better version called pmpolicy, based on different > > principles. More information is available at > > > > http://john.snoop.dk/programs/linux/offbutton/ > To implement off-button you only need the APM_IOC_REJECT ioctl and The problem on my computer with my (re)implementation of APM_IOC_REJECT is that the screen goes into powersaving when the user suspend is received, then turns it back on when APM_IOC_REJECT is sent by apmd. Stephen said this was something wrong with my implementation (???). Anyway it is fixed in my pmpolicy patch, and I don't need no daemon so the code is a lot cleaner and simpler (no binary magic number interfaces). [...] -- http://www.penguinpowered.com/~vii - 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: kernel apm code
David Balazic <[EMAIL PROTECTED]> writes: > John Fremlin wrote: [...] > > > To implement off-button you only need the APM_IOC_REJECT ioctl and > > > > The problem on my computer with my (re)implementation of > > APM_IOC_REJECT is that the screen goes into powersaving when the user > > suspend is received, then turns it back on when APM_IOC_REJECT is sent > > by apmd. > > What is wrong with that ? > Suspend is requested -> suspend is executed > Suspend is canceled (rejected) -> suspend is canceled > > Seems perfectly OK to me. The sequence is in fact: suspend requested by BIOS -> suspend accepted by kernel -> SUSPEND -> suspend rejected by apmd which is passed on by kernel to BIOS -> REJECT=RESUME (if I understand correctly, this is what seems to happen). Sequence should be as in pmpolicy patch: suspend requested by BIOS -> /sbin/powermanger decides to reject -> REJECT [...] > > Anyway it is fixed in my pmpolicy patch, and I don't need no > > daemon so the code is a lot cleaner and simpler (no binary magic > > number interfaces). > > But there should be no policy in the kernel ! ;-) Read the patch. Read the webpage: http://john.snoop.dk/programs/linux/offbutton There is no policy in kernel. -- http://www.penguinpowered.com/~vii - 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: kernel apm code (PR#128)
[EMAIL PROTECTED] writes: [...] > > AFAICS. I hacked together the following patch for it a while ago, > > which updated APM_IOC_REJECT for slightly more recent kernels (be > > warned, I think I made some mistakes) > > Thanks for this, I will review it and post a patch based on it (with > due accredition of course). Not sure that would be an altogether good idea, because I think I made a bit of a hash of it ;-) Did you get Albert Cranford's version? I would recommend it over mine (though I have not yet looked at it). [...] > I did not say the I did not "like the idea of me implementing it, as > some people at linuxcare (including Stephen) want to do it > differently themselves". I did interpolate the connection between these two clauses. If it truely did not exist, I apologise. > What I said the first time was that I preferred the idea of a user > mode daemon interacting with the kernel not the kernel forking and > execing a new process for every event. This has nothing to do with the interface presented to the APM driver. [...] > It is important when implementing an API (and that is what we are > doing) to try to get it as right and stable as possible because > other developers do not like interfaces changing ... Maybe this is true in general but in this particular case the "API" has only one user at the moment, which is APM, so it is hardly a fully fledged abstraction layer. Do you argue that the current pm_send_all interface is superior to the one in my patch? [...] -- http://www.penguinpowered.com/~vii - 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/
[PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)
When the IP address of an interface changes, TCP connections with the
old source address are useless. Applications are not notified of this
and time out ordinarily, just as if nothing had happened. This is
behaviour isn't very helpful when you have a dynamic IP and know
you're probably not going to get the old one back. In that case, you
want processes to get errors when they try to use one of the dead
connections, so they can handle the disconnect more cleanly. Otherwise
fetchmail, etc. can just hang waiting for ages. Andi Kleen implemented
this functionality with a per interface flag in 2.2. See
ftp.suse.com:/pub/people/ak/v2.2/iff-dynamic*.
The following patch against 2.4.0 does it a different way. It
introduces a new ioctl, called SIOCKILLADDR. When this ioctl is
called, it makes all IPv4 sockets with the specified source address
return -ENETRESET when they are used.
Is this the right error number? I wasn't quite sure where the ioctl
should go to be in keeping with convention - I bunged it in
devinet_ioctl.
I patched userspace ppp-2.4.0 to use this functionality. It would be
better if SIOCKILLADDR were not used until we are sure that the new IP
is in fact different from the old one, but pppd in demand mode would
not notice that there were extant connections and so would not bring
up the link - so the problem would not be alleviated. Therefore
SIOCKILLADDR is used on disconnect. The functionality is activated
with the killoldaddr option. I would be happy to document it in the
manpage if it were accepted. Further the build process is cleaned up
slightly, as in the patch I sent on or around 8 October 2000.
diff -u --exclude *~ --recursive linux-2.4.0-orig/include/linux/sockios.h linux-hacked-dynip/include/linux/sockios.h
--- linux-2.4.0-orig/include/linux/sockios.h Sat Dec 30 00:20:32 2000
+++ linux-hacked-dynip/include/linux/sockios.h Sat Jan 27 17:04:34 2001
@@ -65,6 +65,7 @@
#define SIOCDIFADDR 0x8936 /* delete PA address */
#define SIOCSIFHWBROADCAST 0x8937 /* set hardware broadcast addr */
#define SIOCGIFCOUNT 0x8938 /* get number of devices */
+#define SIOCKILLADDR 0x8939 /* kill all connections with this local address */
#define SIOCGIFBR 0x8940 /* Bridging support */
#define SIOCSIFBR 0x8941 /* Set bridging options */
diff -u --exclude *~ --recursive linux-2.4.0-orig/include/net/tcp.h linux-hacked-dynip/include/net/tcp.h
--- linux-2.4.0-orig/include/net/tcp.h Fri Jan 5 21:41:37 2001
+++ linux-hacked-dynip/include/net/tcp.h Sat Jan 27 18:02:21 2001
@@ -787,9 +787,8 @@
extern int tcp_disconnect(struct sock *sk, int flags);
extern void tcp_unhash(struct sock *sk);
-
extern int tcp_v4_hash_connecting(struct sock *sk);
-
+extern void tcp_v4_zap_saddr(u32 saddr);
/* From syncookies.c */
extern struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
diff -u --exclude *~ --recursive linux-2.4.0-orig/net/ipv4/af_inet.c linux-hacked-dynip/net/ipv4/af_inet.c
--- linux-2.4.0-orig/net/ipv4/af_inet.c Tue Jan 2 09:26:19 2001
+++ linux-hacked-dynip/net/ipv4/af_inet.c Sat Jan 27 18:27:38 2001
@@ -854,6 +854,7 @@
case SIOCSIFPFLAGS:
case SIOCGIFPFLAGS:
case SIOCSIFFLAGS:
+ case SIOCKILLADDR:
return(devinet_ioctl(cmd,(void *) arg));
case SIOCGIFBR:
case SIOCSIFBR:
diff -u --exclude *~ --recursive linux-2.4.0-orig/net/ipv4/devinet.c linux-hacked-dynip/net/ipv4/devinet.c
--- linux-2.4.0-orig/net/ipv4/devinet.c Sat Dec 30 00:22:05 2000
+++ linux-hacked-dynip/net/ipv4/devinet.c Sat Jan 27 21:09:48 2001
@@ -510,6 +510,7 @@
case SIOCSIFBRDADDR: /* Set the broadcast address */
case SIOCSIFDSTADDR: /* Set the destination address */
case SIOCSIFNETMASK: /* Set the netmask for the interface */
+ case SIOCKILLADDR: /* Kill all connections with this local address */
if (!capable(CAP_NET_ADMIN))
return -EACCES;
if (sin->sin_family != AF_INET)
@@ -536,7 +537,10 @@
break;
}
- if (ifa == NULL && cmd != SIOCSIFADDR && cmd != SIOCSIFFLAGS) {
+ if (ifa == NULL
+ && cmd != SIOCSIFADDR
+ && cmd != SIOCSIFFLAGS
+ && cmd != SIOCKILLADDR) {
ret = -EADDRNOTAVAIL;
goto done;
}
@@ -646,6 +650,9 @@
ifa->ifa_prefixlen = inet_mask_len(ifa->ifa_mask);
inet_insert_ifa(ifa);
}
+ break;
+ case SIOCKILLADDR: /* Kill all connections with this local address */
+ tcp_v4_zap_saddr(sin->sin_addr.s_addr);
break;
}
done:
diff -u --exclude *~ --recursive linux-2.4.0-orig/net/ipv4/tcp_ipv4.c linux-hacked-dynip/net/ipv4/tcp_ipv4.c
--- linux-2.4.0-orig/net/ipv4/tcp_ipv4.c Fri Jan 5 21:17:42 2001
+++ linux-hacked-dynip/net/ipv4/tcp_ipv4.c Sat Jan 27 18:07:25 2001
@@ -390,6 +390,38 @@
wake_up(&tcp_lhash_wait);
}
+/* Terminate all active connections with a local address equal to
+ * SADDR. If sysctl_ip_dynaddr is set, connections in the SYN_SENT
+ * state are not closed, because their source address will presumably
+ * be rewritten.
+ */
+void tcp_v4_zap_saddr(u32 saddr)
+{
+ int i;
+ rwlock_t *lock;
+ struct so
Re: [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
[...]
> > I patched userspace ppp-2.4.0 to use this functionality. It would be
> > better if SIOCKILLADDR were not used until we are sure that the new IP
> > is in fact different from the old one, but pppd in demand mode would
>
> I get the same IP about 2/3 of the time, so it is pretty important
> to avoid killing connections until after the new IP is known.
I'll try to explain again. If you have an existing (e.g. ssh)
connection to a host across the interface, and the interface comes
down then pppd _will not bring it up again_ until you try to start a
new connection, as far as I have experienced. Therefore you will get
the old behaviour and my patch will do nothing. I decided it was
better to inform ssh that the link was dead.
Like I said, the solution to this is to make pppd cleverer about
bringing the link up when there are existing
connections. Alternatively, you could have some dubious script parsing
netstat checking whether there are connections over the interface.
and pinging hosts at intervals to bring the link up again ;-)
Here is a patch for pppd-2.4.0 orig that will give you the behaviour
you want, provided you can solve the problem in the first
paragraph. It almost exactly the same as my last patch. It compiles
and everything. Note that there are no changes required to the kernel
side patch to enable this functionality.
diff -u --recursive ppp-2.4.0-orig/chat/Makefile.linux ppp-2.4.0-hacked/chat/Makefile.linux
--- ppp-2.4.0-orig/chat/Makefile.linux Fri Aug 13 02:54:32 1999
+++ ppp-2.4.0-hacked/chat/Makefile.linux Sat Jan 27 18:34:47 2001
@@ -6,14 +6,14 @@
CDEF4= -DFNDELAY=O_NDELAY # Old name value
CDEFS= $(CDEF1) $(CDEF2) $(CDEF3) $(CDEF4)
-CFLAGS= -O2 -g -pipe $(CDEFS)
+CFLAGS= $(COPTS) $(CDEFS)
INSTALL= install
all: chat
chat: chat.o
- $(CC) -o chat chat.o
+ $(CC) $(LDFLAGS) -o chat chat.o
chat.o: chat.c
$(CC) -c $(CFLAGS) -o chat.o chat.c
diff -u --recursive ppp-2.4.0-orig/pppd/options.c ppp-2.4.0-hacked/pppd/options.c
--- ppp-2.4.0-orig/pppd/options.c Tue Aug 1 02:38:30 2000
+++ ppp-2.4.0-hacked/pppd/options.c Sat Jan 27 18:51:30 2001
@@ -77,6 +77,9 @@
char user[MAXNAMELEN]; /* Username for PAP */
char passwd[MAXSECRETLEN]; /* Password for PAP */
bool persist = 0; /* Reopen link after it goes down */
+bool killoldaddr = 0; /* If our IP is reassigned on
+reconnect, kill active TCP
+ connections using the old IP. */
char our_name[MAXNAMELEN]; /* Our name for authentication purposes */
bool demand = 0; /* do dial-on-demand */
char *ipparam = NULL; /* Extra parameter for ip up/down scripts */
@@ -194,6 +197,10 @@
"Turn off persist option" },
{ "demand", o_bool, &demand,
"Dial on demand", OPT_INITONLY | 1, &persist },
+{ "killoldaddr", o_bool, &killoldaddr,
+ "Kill connections from an old source address", 1},
+{ "nokilloldaddr", o_bool,&killoldaddr,
+ "Don't kill connections from an old source address" },
{ "--version", o_special_noarg, (void *)showversion,
"Show version number" },
{ "--help", o_special_noarg, (void *)showhelp,
diff -u --recursive ppp-2.4.0-orig/pppd/pppd.h ppp-2.4.0-hacked/pppd/pppd.h
--- ppp-2.4.0-orig/pppd/pppd.h Thu Jul 6 12:17:03 2000
+++ ppp-2.4.0-hacked/pppd/pppd.h Sat Jan 27 20:13:17 2001
@@ -235,6 +235,9 @@
extern char remote_name[MAXNAMELEN]; /* Peer's name for authentication */
extern bool explicit_remote;/* remote_name specified with remotename opt */
extern bool demand; /* Do dial-on-demand */
+extern bool killoldaddr; /* If our IP is reassigned on
+reconnect, kill active TCP
+ connections using the old IP. */
extern char *ipparam; /* Extra parameter for ip up/down scripts */
extern bool cryptpap; /* Others' PAP passwords are encrypted */
extern int idle_time_limit;/* Shut down link if idle for this long */
diff -u --recursive ppp-2.4.0-orig/pppd/sys-linux.c ppp-2.4.0-hacked/pppd/sys-linux.c
--- ppp-2.4.0-orig/pppd/sys-linux.c Wed Jul 26 05:17:12 2000
+++ ppp-2.4.0-hacked/pppd/sys-linux.c Sat Jan 27 21:55:03 2001
@@ -115,6 +115,10 @@
#endif /* INET6 */
+#ifndef SIOCKILLADDR
+#define SIOCKILLADDR 0x8939
+#endif
+
/* We can get an EIO error on an ioctl if the modem has hung up */
#define ok_error(num) ((num)==EIO)
@@ -152,6 +156,7 @@
static u_int32_t proxy_arp_addr; /* Addr for proxy arp entry added */
static char proxy_arp_dev[16]; /* Device for proxy arp entry */
static u_int32_t our_old_addr; /* for detecting address changes */
+static u_int32_t our_current_addr;
static int dynaddr_set; /* 1 if ip_dynaddr set */
static int looped; /* 1 if using loop */
static int link_mtu; /* mtu for the link (not bundle) */
@@ -491,6 +496,27 @@
return -1;
}
+static void do_killaddr(u_int32_t oldaddr)
+{
+struct ifreq ifr;
+
+memset(&ifr,0,sizeof ifr);
+
+SET_SA_FAMILY (ifr.ifr_addr,AF_INET);
+SET_SA_FAMILY (ifr.ifr_dstaddr, AF_INET);
+SET_SA_FAMI
Re: [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)
Jamie Lokier <[EMAIL PROTECTED]> writes: [...] > The important thing is that the tunnel is destroyed and recreated > (it has to be, it is over different underlying link addresses). I > do not want that to destroy the connections from the tunnelled > address. No connections at all will be destroyed by my patch unless you enable the new killoldaddr pppd option. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Disk is cheap?
Robert Kaiser <[EMAIL PROTECTED]> writes: > On Die, 06 Feb 2001 you wrote: > > But paring down the startup scripts is a good idea. For something like an embedded > > device, you might even want to go with a custom init, Plug: How about jinit (my init) ;-) http://www.penguinpowered.com/~vii/programs/linux/jinit http://john.snoop.dk/programs/linux/jinit Boot script time with the supplied example scripts is 12-13 seconds to login prompt under 2.4 on my old K6-2. Jinit has integrated service stop/start functionality. Also on the page are links to other source available inits. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Alexander Viro <[EMAIL PROTECTED]> writes: [...] > We have ~180 first-order ioctl() methods. Several (my guess would be Hehe. I suppose you already know about the way strace (@sourceforge) kind of automatically tries to figure out the args for the common ones? [...] -- http://ape.n3.net - 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/
2.4.4 isapnp - wrong set of resources chosen
Hi! Robin Cull and I have OPL3-SA2 isapnp cards. Sometimes we get assigned the wrong resource set. These cards do not take kindly to Alternate resources 0:1 Priority acceptable, in fact they are completely broke, so it is important to us that they get their first choice ;-) The trouble is that isapnp auto conf does not always take the first choice, even when it is available! This happens to me everytime I unload and reload the opl3sa2 module, but can also be seen after unloading the module by doing card 0 YMH0020 dev 0 YMH0021 deactivate auto activate The second config is chosen (see attached /proc/isapnp). However, activating the first config by hand works fine - on reloading the module it plays sounds just dandy. card 0 YMH0020 dev 0 YMH0021 deactivate port 0 0x220 port 1 0x530 port 2 0x388 port 3 0x330 port 4 0x370 dma 0 0 dma 1 1 irq 0 5 activate isapnp ioports interrupts -- http://ape.n3.net
Re: Problems with arch/i386/kernel/apm.c
Jeff Golds <[EMAIL PROTECTED]> writes: [...] > Please let me know if this is correct, I can provide a simple patch > if needed. What I am really desiring to know is if there are any > devices that depend on the apm::send_event(APM_NORMAL_RESUME) > happening while interrupts are disabled. Yes, USB host controllers -- http://ape.n3.net - 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/
[PATCH] setuid(2) buggy or bad docs
setuid(2) differs from the OpenBSD setuid(2) in that -EPERM is returned by the syscall even if the euid of the process matches the uid passed to it. Either I am non compos or the thing is very wrong. The docs (man-pages-1.35) say ERRORS EPERM The user is not the super-user, and uid does not match the effective or saved user ID of the calling process. The following untested patch changes the kernel to match the documentated behaviour. --- linux-2.4.4-orig/kernel/sys.c Tue May 1 14:34:43 2001 +++ linux-2.4.4/kernel/sys.c Wed Jun 20 01:32:46 2001 @@ -603,7 +603,9 @@ asmlinkage long sys_setuid(uid_t uid) if (uid != old_ruid && set_user(uid, old_euid != uid) < 0) return -EAGAIN; new_suid = uid; - } else if ((uid != current->uid) && (uid != new_suid)) + } else if ((uid != current->uid) + && (uid != new_suid) + && (uid != old_euid)) return -EPERM; if (old_euid != uid) -- Summer job urgently sought due to last minute visa trouble! Please see http://ape.n3.net/cv.html
Re: [slightly OT] IDE problems ? or just a dead disk ?
"David Flynn" <[EMAIL PROTECTED]> writes: [...] > ive done the badblock test, and compiled a list of 2302 bad blocks on this > disk ... however, when running mke2fs -l badblocfile /dev/hdc1 > > i got this interesting errormessage for every one of the bad blocks : > > Bad block 1006290 out of range; ignored. That is probably because badblocks was working with badblocks of a smaller size than that of the filesystem (i.e. probably 1024 bytes instead of 4096 bytes, solution in this case is to divide all bad block numbers by 4). Well that's what happened to me today (worryingly on my newish IBM DTLA hd). -- http://ape.n3.net - 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/
VM tuning through fault trace gathering [with actual code]
Last year I had the idea of tracing the memory accesses of the system
to improve the VM - the traces could be used to test algorithms in
userspace. The difficulty is of course making all memory accesses
fault without destroying system performance.
The following patch (i386 only) will dump all page faults to
/dev/biglog (you need devfs for this node to appear). If you echo 1 >
/proc/sys/vm/trace then *almost all* userspace memory accesses will
take a soft fault. Note that this is a bit suicidal at the moment
because of the staggeringly inefficient way its implemented, on my box
(K6-2 300MHz) only processes which do very little (e.g. /usr/bin/yes)
running at highest priority are able to print anything to the console.
I think the best way would be to have only one valid l2 pte per
process. I'll have a go at doing that in a day or two unless someone
has a better idea?
diff --exclude *~ --new-file -u -r linux-2.4.4-orig/drivers/char/Makefile linux-2.4.4-i386-pagetrace/drivers/char/Makefile
--- linux-2.4.4-orig/drivers/char/Makefile Tue May 1 14:33:51 2001
+++ linux-2.4.4-i386-pagetrace/drivers/char/Makefile Sat Jun 23 22:21:34 2001
@@ -16,7 +16,7 @@
O_TARGET := char.o
-obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o
+obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o biglog.o
# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
diff --exclude *~ --new-file -u -r linux-2.4.4-orig/drivers/char/biglog.c linux-2.4.4-i386-pagetrace/drivers/char/biglog.c
--- linux-2.4.4-orig/drivers/char/biglog.c Thu Jan 1 01:00:00 1970
+++ linux-2.4.4-i386-pagetrace/drivers/char/biglog.c Sun Jun 24 14:55:55 2001
@@ -0,0 +1,204 @@
+/* Implements a misc device that can output large amounts of data from
+ * the kernel to userspace
+ *
+ * (c) 2001 John Fremlin released under GPL
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BUFFER_SIZE (1024*1024*1)
+
+char buffer[BUFFER_SIZE];
+
+static DECLARE_WAIT_QUEUE_HEAD(waiters);
+static spinlock_t write_head_lock = SPIN_LOCK_UNLOCKED;
+unsigned long write_head;
+
+struct fop_priv
+{
+ unsigned long read_head;
+}
+;
+
+void biglog_log(const char*str)
+{
+ const char*i = str;
+ unsigned long head;
+ unsigned long flags;
+
+ spin_lock_irqsave(&write_head_lock,flags);
+ head = write_head;
+ while(*i) {
+ buffer[head++]= *i++;
+ if(head>=BUFFER_SIZE)
+ head = 0;
+ }
+ write_head = head;
+ spin_unlock_irqrestore(&write_head_lock,flags);
+ wake_up_all(&waiters);
+}
+
+void biglog_logfault(struct mm_struct *mm, struct vm_area_struct * vma,
+ unsigned long address, int write_access)
+{
+ static unsigned long no;
+ static char faultbuf[1024];
+
+ char* process = current ? current->comm : "unknown";
+ pid_t pid = current ? current->pid : 0;
+
+ unsigned long offset = address - vma->vm_start;
+ struct file* file = vma->vm_file;
+ struct dentry* dentry = file ? file->f_dentry : 0;
+ struct inode* inode = dentry ? dentry->d_inode : 0;
+
+ unsigned long ino = inode ? inode->i_ino : 0;
+ kdev_t device = inode ? inode->i_dev : 0;
+ struct qstr* d_name = dentry ? &dentry->d_name : 0;
+
+ char name[100];
+ unsigned len = sizeof(name)-1;
+
+ if(d_name && (d_name->len < len))
+ len = d_name->len;
+
+ strncpy(name, d_name ? (const char*)d_name->name : (const char*)
+ "anon", len);
+ name[len] = 0;
+
+ sprintf(faultbuf,"%lu: %p%c (%s) %lu (%s) %p %lu:%lu+%lu\n",
+ no++,
+ (void*)address,
+ write_access?'W':'r',
+ process,
+ (unsigned long)pid,
+ (char*)name,
+ vma,
+ (unsigned long)device,
+ ino,
+ offset
+ );
+
+ biglog_log(faultbuf);
+}
+
+static int fop_open(struct inode * inode, struct file * file)
+{
+ struct fop_priv*priv;
+ priv = kmalloc(sizeof *priv,GFP_KERNEL);
+ if(!priv)
+ return -ENOMEM;
+
+ memset(priv,0,sizeof *priv);
+
+ priv->read_head = write_head;
+ file->private_data = priv;
+
+ return 0;
+}
+
+static ssize_t fop_read(struct file * file, char * buf,
+ size_t count, loff_t *ppos)
+{
+ ssize_t ret = 0;
+ unsigned long head;
+ unsigned long flags;
+ struct fop_priv *priv = (struct fop_priv *)file->private_data;
+
+ if (ppos != &file->f_pos)
+ return -ESPIPE;
+
+ spin_lock_irqsave(&write_head_lock,flags);
+ head = write_head;
+ if(head == priv->read_head) {
+ spin_unlock_irqrestore(&write_head_lock,flags);
+ if(file->f_flags&O_NONBLOCK)
+ return -EAGAIN;
+
+ if (wait_event_interruptible(waiters,
+ head != write_head)
+ == -ERESTARTSYS) {
+ return -ERESTARTSYS;
+ }
+ spin_lock_irqsave(&write_head_lock,flags);
+ head = write_head;
+ }
+ if(!count)
+ goto out;
+
+ if(head >= priv->read_head)
+ if(count > head - priv->read_head)
+ count = head -
Re: VM tuning through fault trace gathering [with actual code]
Rik van Riel <[EMAIL PROTECTED]> writes: > On 25 Jun 2001, John Fremlin wrote: > > > Last year I had the idea of tracing the memory accesses of the > > system to improve the VM - the traces could be used to test > > algorithms in userspace. The difficulty is of course making all > > memory accesses fault without destroying system performance. > > Sounds like a cool idea. One thing you should keep in mind though > is to gather traces of the WHOLE SYSTEM and not of individual > applications. In the current patch all pagefaults are recorded from all sources. I'd like to be able to catch read(2) and write(2) (buffer cache stuff) as well but I don't know how . . . . > There has to be a way to balance the eviction of pages from > applications against those of other applications. Of course! It is important not to regard each thread group as an independent entity IMHO (had a big old argument about this). [...] -- http://ape.n3.net - 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: VM tuning through fault trace gathering [with actual code]
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > On 25 Jun 2001, John Fremlin wrote: > > > > > Last year I had the idea of tracing the memory accesses of the system > > to improve the VM - the traces could be used to test algorithms in > > userspace. The difficulty is of course making all memory accesses > > fault without destroying system performance. [...] > Linux Trace Toolkit (http://www.opersys.com/LTT) does that. I dld the ltt-usenix paper and skim read it. It didn't seem to talk about page faults much. Where should I look? -- http://ape.n3.net - 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: VM tuning through fault trace gathering [with actual code]
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > > Event Time PID Length Description > > > Trap entry 991,299,585,597,016 678 12 TRAP: page fault; >EIP : 0x40067785 That looks like just the generic interrupt handling. It does not do what I want to do, i.e. record some more info about the fault saying where it comes from. -- http://ape.n3.net - 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: A signal fairy tale
Dan Kegel <[EMAIL PROTECTED]> writes: [...] >A signal number cannot be opened more than once concurrently; >sigopen() thus provides a way to avoid signal usage clashes >in large programs. Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? [...] -- http://ape.n3.net - 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: VM Requirement Document - v0.0
Stefan Hoffmeister <[EMAIL PROTECTED]> writes:
[...]
> Windows NT/2000 has flags that can be for each CreateFile operation
> ("open" in Unix terms), for instance
>
> FILE_ATTRIBUTE_TEMPORARY
>
> FILE_FLAG_WRITE_THROUGH
> FILE_FLAG_NO_BUFFERING
> FILE_FLAG_RANDOM_ACCESS
> FILE_FLAG_SEQUENTIAL_SCAN
>
> If Linux does not have mechanism that would allow the signalling of
> specific use case, it might be helpful to implement such a hinting
> system?
madvise(2) does it on mappings IIRC
--
Seeking summer job at last minute - see http://ape.n3.net/cv.html
-
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: VM Requirement Document - v0.0
[...] > immediate: RAM, on-chip cache, etc. > fast: Flash reads, ROMs, etc. > medium:Hard drives, CD-ROMs, 100Mb ethernet, etc. > slow: Flash writes, floppy disks, CD-WR burners > packeted: Reads/write should be in as large a packet as possible > > Embedded Case [...] > Desktop Case I'm not sure there's any point in separating the cases like this. The complex part of the VM is the caching part => to be a good cache you must take into account the speed of accesses to the cached medium, including warm up times for sleepy drives etc. It would be really cool if the VM could do that, so e.g. in the ideal world you could connect up a slow harddrive and have its contents cached as swap on your fast harddrive(!) (not a new idea btw and already implemented elsewhere). I.e. from the point of view of the VM a computer is just a group of data storage units and it's allowed to use up certain parts of each one to do stuff [...] -- http://ape.n3.net - 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: A signal fairy tale
Christopher Smith <[EMAIL PROTECTED]> writes: [...] > >Signals are a pretty dopey API anyway - so instead of trying to > >patch them up, why not think of something better for AIO? > > You assume that this issue only comes up when you're doing AIO. If > we do something that makes signals work better, we can have a much > broader impact that just AIO. If nothing else, the signal usage > clashing issue has nothing to do with AIO. So what. Signals are bad system already. Therefore don't try to force them to do more stuff. Just because they have already been forced to do more doesn't mean it was a good idea at all, or that we should keep on patching bits and pieces onto them, IMHO. -- http://ape.n3.net - 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/
Actual patch for next gen PM interface
This is an attempt at a generic PM event interface for the kernel.
The design is more or less obvious and was laid out in a previous
message. Comments appreciated.
Alan Cox <[EMAIL PROTECTED]> writes:
> > > The entire PM layer for the embedded board I worked on was
> > > 3Kbytes. How small will yours be 8)
> >
> > The generic event interface will be under 3kB, I hope. Would you
> > accept it if so? ;-)
>
> We shall see. I've played with several ideas and never really been
> happy with them so maybe you can solve it
The fruits of today's labour are here. Unfortunately it *is* just over
3kB (but if I understand correctly under 4kB) mostly due to the
generous buffer sizes.
Note that this is prelim work. (Particularly the changes to the APM
stuff need to be looked at, and are not strictly relevant to the patch
at hand.) At the moment, APM events are printed to /dev/pmevent and
kmsg. Suspend requests are no longer acted on by the kernel. This
breaks backward compatibility.
The /dev/pmevent stuff is hopefully pretty feature complete. The
device numbers for it are 10 137. Multiple listeners are allowed etc.
diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-pmevent/arch/i386/kernel/apm.c
--- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001
+++ linux-2.4.4-pmevent/arch/i386/kernel/apm.c Tue May 1 23:47:18 2001
@@ -186,6 +186,7 @@
#include
#include
#include
+#include
#include
#include
@@ -327,7 +328,6 @@
#endif
static int suspends_pending;
static int standbys_pending;
-static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -886,33 +886,6 @@
#endif
}
-static int send_event(apm_event_t event)
-{
- switch (event) {
- case APM_SYS_SUSPEND:
- case APM_CRITICAL_SUSPEND:
- case APM_USER_SUSPEND:
- /* map all suspends to ACPI D3 */
- if (pm_send_all(PM_SUSPEND, (void *)3)) {
- if (event == APM_CRITICAL_SUSPEND) {
-printk(KERN_CRIT "apm: Critical suspend was vetoed, expect armageddon\n" );
-return 0;
- }
- if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- return 0;
- }
- break;
- case APM_NORMAL_RESUME:
- case APM_CRITICAL_RESUME:
- /* map all resumes to ACPI D0 */
- (void) pm_send_all(PM_RESUME, (void *)0);
- break;
- }
-
- return 1;
-}
-
static int suspend(void)
{
int err;
@@ -927,7 +900,6 @@
err = APM_SUCCESS;
if (err != APM_SUCCESS)
apm_error("suspend", err);
- send_event(APM_NORMAL_RESUME);
sti();
queue_event(APM_NORMAL_RESUME, NULL);
for (as = user_list; as != NULL; as = as->next) {
@@ -968,6 +940,43 @@
return 0;
}
+static void announce_event(apm_event_t event)
+{
+ char*type = PME_NOTIFY;
+ char*name;
+
+ if (event <= NR_APM_EVENT_NAME)
+ name = apm_event_name[event - 1];
+ else name = "unknown event";
+
+ switch(event){
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ case APM_CRITICAL_SUSPEND:
+ type = PME_SLEEP;
+ break;
+ case APM_NORMAL_RESUME:
+ case APM_CRITICAL_RESUME:
+ case APM_STANDBY_RESUME:
+ type = PME_WAKE;
+ break;
+ case APM_CAPABILITY_CHANGE:
+ type = PME_NOTIFY;
+ break;
+ case APM_LOW_BATTERY:
+ type = PME_EMERGENCY;
+ break;
+ case APM_POWER_STATUS_CHANGE:
+ type = PME_POWERCHANGE;
+ break;
+ default:
+ type = PME_NOTIFY;
+ }
+ pme_announce(type,"APM",name);
+}
+
static void check_events(void)
{
apm_event_t event;
@@ -989,56 +998,35 @@
if (ignore_normal_resume && (event != APM_NORMAL_RESUME))
ignore_normal_resume = 0;
+ announce_event(event);
+
switch (event) {
case APM_SYS_STANDBY:
case APM_USER_STANDBY:
- if (send_event(event)) {
-queue_event(event, NULL);
-if (standbys_pending <= 0)
- standby();
- }
+ queue_event(event, NULL);
+ if (standbys_pending <= 0)
+standby();
break;
case APM_USER_SUSPEND:
-#ifdef CONFIG_APM_IGNORE_USER_SUSPEND
- if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- break;
-#endif
case APM_SYS_SUSPEND:
- if (ignore_bounce) {
-if (apm_info.connection_version > 0x100)
- apm_set_power_state(APM_STATE_REJECT);
-break;
- }
- /*
- * If we are already processing a SUSPEND,
- * then further SUSPEND events from the BIOS
- * will be ignored. We also return here to
- * cope with the fact that the Thinkpads keep
- * sending a SUSPEND event until something else
- * happens!
+ /* Reject all suspend requests and let
+ * userspace call suspend if they want to
*/
- if (waiting_for_resume)
-return;
- if (send_event(event)) {
-queue_event(event, NULL);
-waiting_for_resume = 1;
-if (suspends_pending <= 0)
- (void) suspend();
- }
+ if (apm_info.connection_version > 0x100)
+apm_set_power_state(APM_STATE_REJECT);
+
+ queue_event(event, NULL);
break;
case APM_NORMAL_RESUME:
case APM_CRITIC
Re: Let init know user wants to shutdown
Pavel Machek <[EMAIL PROTECTED]> writes: > > > > I'm wondering if that veto business is really needed. Why not reject > > > > *all* APM rejectable events, and then let the userspace event handler > > > > send the system to sleep or turn it off? Anybody au fait with the APM > > > > spec? > > > > > > Because apmd is optional > > > > The veto stuff only comes into action, iff someone has registered as > > willing to exercise this power. We would not break compatibility with > > any std kernel by instead having a apmd send a "reject all" ioctl > > instead, and so deal with events without having the pressure of having > > to reject or accept them, and let us remove all the veto code from the > > kernel driver. Or am I missing something? > > No, this looks reasonable. What do you think Stephen and Avery? Are you happy with this idea? If anybody wants to test it, my latest pmevent patch will reject *all* APM events it can. It would be easy to adapt that to turn on and off with an ioctl. I am happy to do that if Stephen would accept it. (Personally would like it if events were rejected by default but that breaks backward compatibility and there is always someone who would get bitten.) The latest pmevent patch (v3) with various APM cleanups is available at http://ape.n3.net/programs/linux/offbutton/download Note that it currently shares no code with the pmpolicy patch. For more information see http://ape.n3.net/programs/linux/offbutton/ -- http://ape.n3.net - 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: [PATCH] zero^H^H^H^Hsingle copy pipe
[Stuff about NetBSD pipes snipped] I'm testing out Manfred's patch for zero copy pipes, and haven't crashed it yet. My hardware is a AMD K6-2 (stepping 1) on an ALi M1541 with 320 Mb - one quite slow 64 Mb stick and one fast 256 Mb stick. The lmbench bw_pipe showed a performance improvement of about 30% from 45 (+- 2) Mb/s to 59.5 (+-0.6) Mb/s. The lmbench (2beta3) lat_pipe showed a performance improvement of about 20% from a latency of about 27 (+- 1) usec to about 22.4 (+-.6) usec. There was one outlyer amoung the 10 non zc pipe runs - 25 usec. For zc, the first run was always about 25 usec and after that very stable around 22 usec. FWIW the system time from "time" when running (bw_pipe;lat_pipe) 10 times in a row *increased* by 50%, from sys 0m18.740s to sys 0m31.660s. Script: for i in 1 2 3 4 5 6 7 8 9 10; do ./bw_pipe; ./lat_pipe; done Non zero copy: real0m49.602s user0m10.170s sys 0m18.740s Zero copy run 1: real0m47.901s user0m10.390s sys 0m31.660s Zero copy run 2: real0m47.492s user0m10.600s sys 0m31.340s -- http://ape.n3.net - 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/
simple userspace pm interface
Here is a patch to deal with PM events (e.g. button presses) in a
system independent way. Could people with the applicable hardware test
out or comment on the changes?
The files affected are
arch/i386/kernel/apm.c
arch/mips/sgi/kernel/reset.c
arch/mips64/sgi-ip22/ip22-reset.c
arch/sparc64/kernel/power.c
drivers/acpi/driver.c
drivers/char/nwbutton.c
drivers/char/nwbutton.h
There are many power management and button press drivers in the
kernel. They all tend to have their own interface to distribute events
to userspace. This is bad, because it means duplicated code, and
requires arch specific userspace whatnots, which should not be
necessary.
Specifically, at the moment, the following approaches are taken by
various subsystems:
- launch /sbin/shutdown
- signal init
- do nothing
And there 3 or so different special devices that userspace can read to
see events. After this patch there are only 2 that I know of (ACPI and
/dev/boxevent, perhaps the ACPI stuff could also be removed, I didn't
look).
The patch converts the PM drivers I found to use a single
interface. (Only APM is tested because nobody has given me e.g. a
SPARC box: i.e. the patch is just a suggestion.)
The kernel interface is very simple. Each driver just does
#include
void button_interrupt() {
boxevent(BUTTONEVENT_OFF,"TurboSnail","button pressed");
}
and the event is exported to any number of userspace listeners on
/dev/boxevent. Thereby writing a new power button driver does not
involve having to deal with all the baggage of device nodes, etc.
You can create /dev/boxevent with mknod boxevent c 10 137
You can see what events occur simply by "cat"ing it to the console.
The format is very simple.
Where is one of the strings OFF,SLEEP,WAKE,EMERGENCY,NOTIFY
(if a reader does not read events quickly enough, it will get a
MSGFLOOD event), is a space character, is a word
denoting the kernel pm interface responsible for generating the event,
is an arbitrary string. is a newline character \n.
This is flexible. It means a reasonable default behaviour can be
suggested by the kernel (OFF,SLEEP,etc.) for events that userspace
doesn't know about, but userspace can choose fine grained policy and
provide helpful error messages based on the exact event name by
checking the description.
In fact, here is the "daemon" I use
#! /bin/perl
use Sys::Syslog qw(:DEFAULT setlogsock);
sub do_off {
system("/sbin/shutdown -p now");
exit(0);
}
sub do_overflow {
setlogsock("unix");
openlog("boxd","cons","daemon");
syslog('err',"messages arriving too fast");
closelog();
}
while(<>){
if(/MSGFLOOD/) {
do_overflow();
next
}
if(/^SLEEP APM user suspend/){
do_off();
next
}
if(/^OFF/){
do_off();
next
}
}
The patch against 2.4.4 is attached.
diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-boxevent/arch/i386/kernel/apm.c
--- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001
+++ linux-2.4.4-boxevent/arch/i386/kernel/apm.c Mon May 7 15:36:53 2001
@@ -148,6 +148,9 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Move most of the /dev/apm_bios stuff to drivers/char/boxevent.c
+ * Reject all events by default
+ * (John Fremlin <[EMAIL PROTECTED]>)
*
* APM 1.1 Reference:
*
@@ -186,6 +189,7 @@
#include
#include
#include
+#include
#include
#include
@@ -301,10 +305,6 @@
int suser: 1;
int suspend_wait: 1;
int suspend_result;
- int suspends_pending;
- int standbys_pending;
- int suspends_read;
- int standbys_read;
int event_head;
int event_tail;
apm_event_t events[APM_MAX_EVENTS];
@@ -325,8 +325,7 @@
#ifdef CONFIG_APM_CPU_IDLE
static int clock_slowed;
#endif
-static int suspends_pending;
-static int standbys_pending;
+static int suspend_launched;
static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -352,7 +351,7 @@
static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
static struct apm_user * user_list;
-static char driver_version[] = "1.14"; /* no spaces */
+static char driver_version[] = "1.15"; /* no spaces */
static char * apm_event_name[] = {
"system standby",
@@ -579,56 +578,6 @@
clock_slowed = 0;
}
}
-
-#if 0
-extern int hlt_counter;
-
-/*
- * If no process has been interested in this
- * CPU for some time, we want to wake up the
- * p
Re: simple userspace pm interface
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> - It's probably easier to put the "event" file in proc, instead of
> dev. This is what the acpi interface does, and eliminates the mknod
> step.
Is this kernel policy? I mean, you could apply the same argument to
all device nodes ;-)
> - perhaps rename boxevent() to event() or sys_event()?
Event is a bit generic, and sys_event is vague. I agree that boxevent
is not a pretty name, but it gives a vague suggestion of
hardwareness. hwevent looks ugly - what do people think?
> - Consider putting the subsystem/class identifier first
> - Consider hiding the source of the event. For example, we shouldn't care
> that the power button press was generated by APM or MIPS64, because we're
> going to take the same action, regardless.
The suggested action is given as the first word. The second word is
the subsystem, in order to avoid namespace collisions: you could have
two different PM systems active on your machine at different times,
(e.g. ACPI and APM) and this lets you distinguish between them. You
could think of it as the first word being the suggested action and the
rest being a description.
> I'd encourage you to take a look at the ACPI code that does
> something similar (in 2.4.4ac4 or greater, or grab the code from the
> website at
> http://developer.intel.com/technology/iapc/acpi/downloads.htm .)
> Specifically, grep -r for bm_osl_generate_event(). Modifying that
> code to be more general-purpose could possibly meet ACPI's needs as
> well as everyone else's.
ACPI_STATUS bm_osl_generate_event (
BM_HANDLE device_handle,
char*device_type,
char*device_instance,
u32 event_type,
u32 event_data)
{
The function could quickly be converted to boxevent without thinking
sprintf(buffer,"device %s instance %s says %x: %x",
device_type,device_instance,event_type,event_data);
boxevent(BOXEVENT_NOTIFY,"ACPI",buffer);
this would provide all of the current functionality available from
ACPI (ATM the code does sprintf(str, "%s %s %08x %08x\n") to the
userspace reader) but boxevent also handles poll, short reads, and
event floods, etc.
Some one who knows about ACPI could change the BOXEVENT_NOTIFY to a
better suggestion based on event_type or something.
[...]
--
http://ape.n3.net
-
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: LANANA: To Pending Device Number Registrants
Linus Torvalds <[EMAIL PROTECTED]> writes: [...] > Nobody really uses it because it would require you to add a line or > two to your init scripts to pick up the major number from > /proc/devices, and that's obviously too hard. Much better to just > hardcode randome numbers, right? And thereby avoid using procfs. Hardcoding is the way the BSDs seem to be going. Clueless suggestion: I suppose you could allocate numbers on kernel build or something. [...] -- http://ape.n3.net - 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/
