Pete Zaitcev wrote:
Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Tuesday 23 March 2004 01:28 schrieb Pete Zaitcev:

I strongly disagree with this point of view. Keeping track of a context in which a function can be called places an unreasonable burden on a programmer and introduces extremely annoying code rot whenever code migrates contexts.

This is an argument for documented calling conventions. That handles the "keep track" bit: "may sleep" is a particularly strong statement.


You cannot efficiently write code that runs under several contexts.
Too many things mostly related to the ability to sleep depend on the
context. We continously get buggy drivers which sleep in interrupt
because people are not aware.

... or are just sloppy, or maybe they even need to cope with a botched API (like the serial layer) which turns calls that normally sleep into "must not sleep" calls. Even documenting the conventions (which the serial layer doesn't do!) can't really recover from design botches like that.

One of the 2.6 usbcore changes of this type was to explicitly
pass GFP_* flags in many cases.  In 2.4, usbcore and the HCDs
had to guess whether GFP_KERNEL was usable; and "wrong!" was
of course sometimes the result.


What you say is true for any non-trivial code, especially if it does
any memory allocations. We learned this at a high price with Youngdale's
SCSI which basically made programmers to assume an interrupt context
throughout the stack and thus precluded GFP_KERNEL completely.

I'm not sure I understand what you're saying about SCSI, but clearly that result was not good.

- Dave




------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to