RE: Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compilefailure
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > > Greg KH wrote: > > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote: > > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- > > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and > > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. > > > > Argh! > > I thought the whole point of this was to make there be only > one hotplug > > strategy, due to the fact that this is a real need. > > > > Please let's not go down this path. It was all starting to look so > > nice... > > I -want- there to be only one hotplug strategy, but Adam seemed to be > talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. I told Adam that I didn't want that patch, but it's not up to me now. > I'm hoping that Linus will disagree with the splintering of > CONFIG_HOTPLUG too... And JE. > I think it's too late in 2.4.x cycle to change now anyway. And I told Adam that also. > Jeff ~Randy - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
> = Greg KH >> = Jeff Garzik >> I -want- there to be only one hotplug strategy, but Adam seemed to be >> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. >Here's Adam's proposal for CONFIG_USB_HOTPLUG: > http://www.geocrawler.com/lists/3/SourceForge/2571/250/4599696/ Thanks, Greg! >>From what I remember (and from looking at this message), all he seems to >want is to redefine the __init and __initdata macros depending on a >config item. There's no other grander scheme of things, right Adam? Yes, I would have __usbdev{init,exit}{,data} be defined based on CONFIG_USB_HOTPLUG. >Although such a small memory savings for turning a bus whose main goal >in life is to enable hot plugged devices into a fixed connection doesn't >seem worth it. [...] >Comments Adam? There would be more memory savings from tagging all USB device driver initialization and exit routines with __usbdevinit and __usbdevexit. Although hot plugging is a convenient feature of USB, there are plenty of applications of USB that do not use hot plugging. For example, imagine some kind of kiosk or internet appliciance that uses a USB keyboard or camera, because that is the commodity hardware, but which the user is not able to physically unplug. Perhaps this embedded would get cost benefits from a smaller kernel. That is the sort of potential use that I can imagine for "CONFIG_USB_HOTPLUG=n". As I said, I am interested in feedback from potential users of CONFIG_USB_HOTPLUG=n to determine if anyone would use it or if it is just an intellectual exercise. The part that is more clearly useful is being able to have USB hot plugging without compiling in PCI hot plugging. So, CONFIG_HOTPLUG be CONFIG_PCI_HOTPLUG, or at least should be thought of that way, regardless of whether CONFIG_USB_HOTPLUG is added. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
= Greg KH = Jeff Garzik I -want- there to be only one hotplug strategy, but Adam seemed to be talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. Here's Adam's proposal for CONFIG_USB_HOTPLUG: http://www.geocrawler.com/lists/3/SourceForge/2571/250/4599696/ Thanks, Greg! From what I remember (and from looking at this message), all he seems to want is to redefine the __init and __initdata macros depending on a config item. There's no other grander scheme of things, right Adam? Yes, I would have __usbdev{init,exit}{,data} be defined based on CONFIG_USB_HOTPLUG. Although such a small memory savings for turning a bus whose main goal in life is to enable hot plugged devices into a fixed connection doesn't seem worth it. [...] Comments Adam? There would be more memory savings from tagging all USB device driver initialization and exit routines with __usbdevinit and __usbdevexit. Although hot plugging is a convenient feature of USB, there are plenty of applications of USB that do not use hot plugging. For example, imagine some kind of kiosk or internet appliciance that uses a USB keyboard or camera, because that is the commodity hardware, but which the user is not able to physically unplug. Perhaps this embedded would get cost benefits from a smaller kernel. That is the sort of potential use that I can imagine for "CONFIG_USB_HOTPLUG=n". As I said, I am interested in feedback from potential users of CONFIG_USB_HOTPLUG=n to determine if anyone would use it or if it is just an intellectual exercise. The part that is more clearly useful is being able to have USB hot plugging without compiling in PCI hot plugging. So, CONFIG_HOTPLUG be CONFIG_PCI_HOTPLUG, or at least should be thought of that way, regardless of whether CONFIG_USB_HOTPLUG is added. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
From: Jeff Garzik [mailto:[EMAIL PROTECTED]] Greg KH wrote: On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote: If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. Argh! I thought the whole point of this was to make there be only one hotplug strategy, due to the fact that this is a real need. Please let's not go down this path. It was all starting to look so nice... I -want- there to be only one hotplug strategy, but Adam seemed to be talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. I told Adam that I didn't want that patch, but it's not up to me now. I'm hoping that Linus will disagree with the splintering of CONFIG_HOTPLUG too... And JE. I think it's too late in 2.4.x cycle to change now anyway. And I told Adam that also. Jeff ~Randy - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
Jeff Garzik wrote: >"Adam J. Richter" wrote: >> If a programmer errs in favor of __devinit, the result is >> extra memory consumption under CONFIG_HOTPLUG. If a programmer >> errs in favor of __init, the result is a crash during hot p >> ug insertion. Avoiding crashes at the expensive of a pretty small >> amount of memory usage is the more "conservative" way to err. >You suggest avoiding correctness in order to protect against dumb >programmers. That path leads to Windows. No, I was saying that if you are unsure whether to use __devinit{,data} or __init{,data}, using __dev version more closely fulfulls your request that we "Please err on the conservative side." If you are sure of the correct one to use, then, of course, I am sure we all agree you should use it. >> Having USB hot plugging without needing to build in PCI >> hot plugging is useful, >Of course. But CONFIG_HOTPLUG does not mean PCI hotplugging. It means >any hotplug support in the kernel. That is why __devinit exists and is >used in a generic fashion. Could you please cite an example or two of where __devinit is currently correctly used for a non-PCI non-USB device? I think you can skip the places in the ISA parallel port code where it is apparently being incorrectly used (where some non-hot-pluggable ISA code that could safely be freed will be retained if the kernel is compied with CONFIG_HOTPLUG). Earlier in your email, you made an argument about the development culture ("That path leads to Windows"). In that same spirit, let's not rely on bureaucratic doctrines like "But CONFIG_HOTPLUG does not mean..." and, instead, let's look at the underlying technical issues, which I believe are: 1. there is essentially no call graph dependency between the hot plugging mechanisms of different busses, 2. we agree that having USB hot plugging without needing to build in PCI hot plugging is useful. >> After 2.4.0, [...] we may >> want to explore adding __usbdevinit{,data} defines in include/linux/init.h >> that would be controlled by a new CONFIG_USB_HOTPLUG option, as in >> the patches that I posted for this to linux-usb-devel. >This is not just a USB issue. Please discuss this on linux-kernel, so >we can have a coherent hotplug strategy for the entire kernel. >If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- >CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and >CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. s/must/should/ (since you are not changing the resulting binary) I agree that CONFIG_HOTPLUG should be renamed CONFIG_PCI_HOTPLUG and I would further like to see __devinit{,data} become __pcidevinit{,data}. Not only does this configurability have real world uses, but the clearer labelling would also make the effected code a little more self documenting as to why the code and data in question is not just __init{,data}. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Wed, Nov 15, 2000 at 12:54:35AM -0500, Jeff Garzik wrote: > > I -want- there to be only one hotplug strategy, but Adam seemed to be > talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. Here's Adam's proposal for CONFIG_USB_HOTPLUG: http://www.geocrawler.com/lists/3/SourceForge/2571/250/4599696/ >From what I remember (and from looking at this message), all he seems to want is to redefine the __init and __initdata macros depending on a config item. There's no other grander scheme of things, right Adam? Although such a small memory savings for turning a bus whose main goal in life is to enable hot plugged devices into a fixed connection doesn't seem worth it. We are talking embedded USB hosts here, not devices. USB devices running Linux is a whole 'nother thing, which I'm just now starting to look into... Comments Adam? thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
Greg KH wrote: > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote: > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. > > Argh! > I thought the whole point of this was to make there be only one hotplug > strategy, due to the fact that this is a real need. > > Please let's not go down this path. It was all starting to look so > nice... I -want- there to be only one hotplug strategy, but Adam seemed to be talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. I'm hoping that Linus will disagree with the splintering of CONFIG_HOTPLUG too... I think it's too late in 2.4.x cycle to change now anyway. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote: > > This is not just a USB issue. Please discuss this on linux-kernel, so > we can have a coherent hotplug strategy for the entire kernel. I agree. If I see the topic come up on linux-usb-devel again, I'll push it over to linux-kernel. > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. Argh! I thought the whole point of this was to make there be only one hotplug strategy, due to the fact that this is a real need. Please let's not go down this path. It was all starting to look so nice... greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
"Adam J. Richter" wrote: > If a programmer errs in favor of __devinit, the result is > extra memory consumption under CONFIG_HOTPLUG. If a programmer > errs in favor of __init, the result is a crash during hot p > ug insertion. Avoiding crashes at the expensive of a pretty small > amount of memory usage is the more "conservative" way to err. You suggest avoiding correctness in order to protect against dumb programmers. That path leads to Windows. > >Otherwise, you rob CONFIG_HOTPLUG people of some memory that could > >otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is > >not small, it includes not only the CardBus users but USB users too... > > We have been discussing this on linux-devel-usb. The > latest patches submitted to Linus and in 2.4.0-test10-pre{3,4} > support USB hot plugging regardless of whether CONFIG_HOTPLUG is > specified. > > bash% find linux-2.4.0-test11-pre4/drivers/usb -type f | xargs egrep HOTPLUG Read the code. test11-pre[34] was broken due to my recent CONFIG_KMOD/CONFIG_HOTPLUG separation, and should have had CONFIG_HOTPLUG. test11-pre5 has CONFIG_HOTPLUG. As it should. > Having USB hot plugging without needing to build in PCI > hot plugging is useful, Of course. But CONFIG_HOTPLUG does not mean PCI hotplugging. It means any hotplug support in the kernel. That is why __devinit exists and is used in a generic fashion. > After 2.4.0, [...] we may > want to explore adding __usbdevinit{,data} defines in include/linux/init.h > that would be controlled by a new CONFIG_USB_HOTPLUG option, as in > the patches that I posted for this to linux-usb-devel. This is not just a USB issue. Please discuss this on linux-kernel, so we can have a coherent hotplug strategy for the entire kernel. If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
In the particular case of yss225.c, I understand now that it is ISA only, which is not hot pluggable, so __initdata should be fine; however, I would like to respond to some other points that Jeff Garzik raised. Jeff Garzik wrote: >Please err on the conservative side -- IMHO you shouldn't mark a driver >as hotpluggable (by using the '__dev' prefix) unless you know it is >necessary. To the best of my knowledge, using __devinit does not "mark" a driver as hot pluggable. All __devinit{,data} does is resolve to __init{,data} if CONFIG_HOTPLUG is undefined, and resolve to nothing if CONFIG_HOTPLUG is defined. If a programmer errs in favor of __devinit, the result is extra memory consumption under CONFIG_HOTPLUG. If a programmer errs in favor of __init, the result is a crash during hot p ug insertion. Avoiding crashes at the expensive of a pretty small amount of memory usage is the more "conservative" way to err. >Otherwise, you rob CONFIG_HOTPLUG people of some memory that could >otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is >not small, it includes not only the CardBus users but USB users too... We have been discussing this on linux-devel-usb. The latest patches submitted to Linus and in 2.4.0-test10-pre{3,4} support USB hot plugging regardless of whether CONFIG_HOTPLUG is specified. bash% find linux-2.4.0-test11-pre4/drivers/usb -type f | xargs egrep HOTPLUG bash% Having USB hot plugging without needing to build in PCI hot plugging is useful, since there are lots of devices that lack PCI hot plugging hardware but support USB hot plugging, including, for example, almost all desktop PC's and typical "appliance" devices. In addition, other places in the USB code have always relied on hot plugging by simulating a disconnect and reconnect to recover from some errors, a kludge which could potentially result in loss of some device state, but which is too complex to fix before 2.4.0. After 2.4.0, and after the fake disconnect/reconnect code in drivers/usb/{devio,storage/scsiglue}.c is designed out, then we may want to explore adding __usbdevinit{,data} defines in include/linux/init.h that would be controlled by a new CONFIG_USB_HOTPLUG option, as in the patches that I posted for this to linux-usb-devel. In that case, CONFIG_USB_HOTPLUG=y would give you the current behavior and CONFIG_USB_HOTPLUG=n would give you a slightly smaller kernel that lacked the ability to support USB hot plugging. There is some question as to whether CONFIG_USB_HOTPLUG=n would just be a cool hack or if someone actually would use it. I am very interested in feeback on this question. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Tue, 14 Nov 2000, Jeff Garzik wrote: > Bartlomiej Zolnierkiewicz wrote: > > > > On Mon, 13 Nov 2000, Adam J. Richter wrote: > > > > > linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata > > > but does not include , so it could not compile. I have > > > attached below. > > > > > > Note that I am a bit uncertain about the correctness of > > > the __initdata prefix here in the first place. Is yss225 a PCI > > > device? If so, a kernel that supports PCI hot plugging should > > > be prepared to support the possibility of a hot pluggable yss225 > > > card being inserted after the module has already been initialized. > > > Even if no CardBus or CompactPCI version of yss225 hardware exists > > > yet, it will require less maintenance for PCI drivers to be prepared > > > for this possibility from the outset (besides, is it possible to have a > > > hot pluggable PCI bridge card that bridges to a regular PCI bus?). > > > > Good question > I mean question about h-p PCI bridge card that bridges regular PCI bus... > Please err on the conservative side -- IMHO you shouldn't mark a driver > as hotpluggable (by using the '__dev' prefix) unless you know it is > necessary. > > Otherwise, you rob CONFIG_HOTPLUG people of some memory that could > otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is > not small, it includes not only the CardBus users but USB users too... > > Jeff I fully agree. That's why "hotplugging" drivers requires some more effort then just adding __devfoo instead of __foo. Jeff, have you read last coment in my mail? -- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
Bartlomiej Zolnierkiewicz wrote: > > On Mon, 13 Nov 2000, Adam J. Richter wrote: > > > linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata > > but does not include , so it could not compile. I have > > attached below. > > > > Note that I am a bit uncertain about the correctness of > > the __initdata prefix here in the first place. Is yss225 a PCI > > device? If so, a kernel that supports PCI hot plugging should > > be prepared to support the possibility of a hot pluggable yss225 > > card being inserted after the module has already been initialized. > > Even if no CardBus or CompactPCI version of yss225 hardware exists > > yet, it will require less maintenance for PCI drivers to be prepared > > for this possibility from the outset (besides, is it possible to have a > > hot pluggable PCI bridge card that bridges to a regular PCI bus?). > > Good question Please err on the conservative side -- IMHO you shouldn't mark a driver as hotpluggable (by using the '__dev' prefix) unless you know it is necessary. Otherwise, you rob CONFIG_HOTPLUG people of some memory that could otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is not small, it includes not only the CardBus users but USB users too... Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Mon, 13 Nov 2000, Adam J. Richter wrote: > linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata > but does not include , so it could not compile. I have > attached below. > > Note that I am a bit uncertain about the correctness of > the __initdata prefix here in the first place. Is yss225 a PCI > device? If so, a kernel that supports PCI hot plugging should > be prepared to support the possibility of a hot pluggable yss225 > card being inserted after the module has already been initialized. > Even if no CardBus or CompactPCI version of yss225 hardware exists > yet, it will require less maintenance for PCI drivers to be prepared > for this possibility from the outset (besides, is it possible to have a > hot pluggable PCI bridge card that bridges to a regular PCI bus?). Good question > > So, if yss225 is a PCI device, the declaration should use > __devinitdata. On the other hand, if it is ISA only, then __initdata > should be correct. Currently not a problem because yss225.c is used only by wavfront.c which is a driver for Turtle Beach WaveFront Series (ISA)... > > Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 > [EMAIL PROTECTED] \ / San Jose, California 95129-1034 > +1 408 261-6630 | g g d r a s i l United States of America > fax +1 408 261-6631 "Free Software For The Rest Of Us." > > --- linux-2.4.0-test11-pre4/drivers/sound/yss225.cMon Nov 13 13:36:50 2000 > +++ linux/drivers/sound/yss225.c Mon Nov 13 09:11:02 2000 > @@ -1,3 +1,4 @@ > +#include > unsigned char page_zero[] __initdata = { > 0x01, 0x7c, 0x00, 0x1e, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf5, 0x00, > 0x11, 0x00, 0x20, 0x00, 0x32, 0x00, 0x40, 0x00, 0x13, 0x00, 0x00, > Rasmus Andersen have already posted three patches which fix my temporary braindamage (linux/init.h)... Right know I don't care too much about hotplugging because most of drivers are broken anyway (or not?)... I _will_ try to fix hotplugging later (I'm talking not only about sound)... as it needs some further investigation... Regards -- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Mon, 13 Nov 2000, Adam J. Richter wrote: linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata but does not include linux/init.h, so it could not compile. I have attached below. Note that I am a bit uncertain about the correctness of the __initdata prefix here in the first place. Is yss225 a PCI device? If so, a kernel that supports PCI hot plugging should be prepared to support the possibility of a hot pluggable yss225 card being inserted after the module has already been initialized. Even if no CardBus or CompactPCI version of yss225 hardware exists yet, it will require less maintenance for PCI drivers to be prepared for this possibility from the outset (besides, is it possible to have a hot pluggable PCI bridge card that bridges to a regular PCI bus?). Good question So, if yss225 is a PCI device, the declaration should use __devinitdata. On the other hand, if it is ISA only, then __initdata should be correct. Currently not a problem because yss225.c is used only by wavfront.c which is a driver for Turtle Beach WaveFront Series (ISA)... Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." --- linux-2.4.0-test11-pre4/drivers/sound/yss225.cMon Nov 13 13:36:50 2000 +++ linux/drivers/sound/yss225.c Mon Nov 13 09:11:02 2000 @@ -1,3 +1,4 @@ +#include linux/init.h unsigned char page_zero[] __initdata = { 0x01, 0x7c, 0x00, 0x1e, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf5, 0x00, 0x11, 0x00, 0x20, 0x00, 0x32, 0x00, 0x40, 0x00, 0x13, 0x00, 0x00, Rasmus Andersen have already posted three patches which fix my temporary braindamage (linux/init.h)... Right know I don't care too much about hotplugging because most of drivers are broken anyway (or not?)... I _will_ try to fix hotplugging later (I'm talking not only about sound)... as it needs some further investigation... Regards -- Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
Bartlomiej Zolnierkiewicz wrote: On Mon, 13 Nov 2000, Adam J. Richter wrote: linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata but does not include linux/init.h, so it could not compile. I have attached below. Note that I am a bit uncertain about the correctness of the __initdata prefix here in the first place. Is yss225 a PCI device? If so, a kernel that supports PCI hot plugging should be prepared to support the possibility of a hot pluggable yss225 card being inserted after the module has already been initialized. Even if no CardBus or CompactPCI version of yss225 hardware exists yet, it will require less maintenance for PCI drivers to be prepared for this possibility from the outset (besides, is it possible to have a hot pluggable PCI bridge card that bridges to a regular PCI bus?). Good question Please err on the conservative side -- IMHO you shouldn't mark a driver as hotpluggable (by using the '__dev' prefix) unless you know it is necessary. Otherwise, you rob CONFIG_HOTPLUG people of some memory that could otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is not small, it includes not only the CardBus users but USB users too... Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Tue, 14 Nov 2000, Jeff Garzik wrote: Bartlomiej Zolnierkiewicz wrote: On Mon, 13 Nov 2000, Adam J. Richter wrote: linux-2.4.0-test11-pre4/drivers/sound/yss225.c uses __initdata but does not include linux/init.h, so it could not compile. I have attached below. Note that I am a bit uncertain about the correctness of the __initdata prefix here in the first place. Is yss225 a PCI device? If so, a kernel that supports PCI hot plugging should be prepared to support the possibility of a hot pluggable yss225 card being inserted after the module has already been initialized. Even if no CardBus or CompactPCI version of yss225 hardware exists yet, it will require less maintenance for PCI drivers to be prepared for this possibility from the outset (besides, is it possible to have a hot pluggable PCI bridge card that bridges to a regular PCI bus?). Good question I mean question about h-p PCI bridge card that bridges regular PCI bus... Please err on the conservative side -- IMHO you shouldn't mark a driver as hotpluggable (by using the '__dev' prefix) unless you know it is necessary. Otherwise, you rob CONFIG_HOTPLUG people of some memory that could otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is not small, it includes not only the CardBus users but USB users too... Jeff I fully agree. That's why "hotplugging" drivers requires some more effort then just adding __devfoo instead of __foo. Jeff, have you read last coment in my mail? -- Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
In the particular case of yss225.c, I understand now that it is ISA only, which is not hot pluggable, so __initdata should be fine; however, I would like to respond to some other points that Jeff Garzik raised. Jeff Garzik wrote: Please err on the conservative side -- IMHO you shouldn't mark a driver as hotpluggable (by using the '__dev' prefix) unless you know it is necessary. To the best of my knowledge, using __devinit does not "mark" a driver as hot pluggable. All __devinit{,data} does is resolve to __init{,data} if CONFIG_HOTPLUG is undefined, and resolve to nothing if CONFIG_HOTPLUG is defined. If a programmer errs in favor of __devinit, the result is extra memory consumption under CONFIG_HOTPLUG. If a programmer errs in favor of __init, the result is a crash during hot p ug insertion. Avoiding crashes at the expensive of a pretty small amount of memory usage is the more "conservative" way to err. Otherwise, you rob CONFIG_HOTPLUG people of some memory that could otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is not small, it includes not only the CardBus users but USB users too... We have been discussing this on linux-devel-usb. The latest patches submitted to Linus and in 2.4.0-test10-pre{3,4} support USB hot plugging regardless of whether CONFIG_HOTPLUG is specified. bash% find linux-2.4.0-test11-pre4/drivers/usb -type f | xargs egrep HOTPLUG bash% Having USB hot plugging without needing to build in PCI hot plugging is useful, since there are lots of devices that lack PCI hot plugging hardware but support USB hot plugging, including, for example, almost all desktop PC's and typical "appliance" devices. In addition, other places in the USB code have always relied on hot plugging by simulating a disconnect and reconnect to recover from some errors, a kludge which could potentially result in loss of some device state, but which is too complex to fix before 2.4.0. After 2.4.0, and after the fake disconnect/reconnect code in drivers/usb/{devio,storage/scsiglue}.c is designed out, then we may want to explore adding __usbdevinit{,data} defines in include/linux/init.h that would be controlled by a new CONFIG_USB_HOTPLUG option, as in the patches that I posted for this to linux-usb-devel. In that case, CONFIG_USB_HOTPLUG=y would give you the current behavior and CONFIG_USB_HOTPLUG=n would give you a slightly smaller kernel that lacked the ability to support USB hot plugging. There is some question as to whether CONFIG_USB_HOTPLUG=n would just be a cool hack or if someone actually would use it. I am very interested in feeback on this question. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
"Adam J. Richter" wrote: If a programmer errs in favor of __devinit, the result is extra memory consumption under CONFIG_HOTPLUG. If a programmer errs in favor of __init, the result is a crash during hot p ug insertion. Avoiding crashes at the expensive of a pretty small amount of memory usage is the more "conservative" way to err. You suggest avoiding correctness in order to protect against dumb programmers. That path leads to Windows. Otherwise, you rob CONFIG_HOTPLUG people of some memory that could otherwise be freed at boot. And the number of CONFIG_HOTPLUG people is not small, it includes not only the CardBus users but USB users too... We have been discussing this on linux-devel-usb. The latest patches submitted to Linus and in 2.4.0-test10-pre{3,4} support USB hot plugging regardless of whether CONFIG_HOTPLUG is specified. bash% find linux-2.4.0-test11-pre4/drivers/usb -type f | xargs egrep HOTPLUG Read the code. test11-pre[34] was broken due to my recent CONFIG_KMOD/CONFIG_HOTPLUG separation, and should have had CONFIG_HOTPLUG. test11-pre5 has CONFIG_HOTPLUG. As it should. Having USB hot plugging without needing to build in PCI hot plugging is useful, Of course. But CONFIG_HOTPLUG does not mean PCI hotplugging. It means any hotplug support in the kernel. That is why __devinit exists and is used in a generic fashion. After 2.4.0, [...] we may want to explore adding __usbdevinit{,data} defines in include/linux/init.h that would be controlled by a new CONFIG_USB_HOTPLUG option, as in the patches that I posted for this to linux-usb-devel. This is not just a USB issue. Please discuss this on linux-kernel, so we can have a coherent hotplug strategy for the entire kernel. If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote: This is not just a USB issue. Please discuss this on linux-kernel, so we can have a coherent hotplug strategy for the entire kernel. I agree. If I see the topic come up on linux-usb-devel again, I'll push it over to linux-kernel. If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. Argh! I thought the whole point of this was to make there be only one hotplug strategy, due to the fact that this is a real need. Please let's not go down this path. It was all starting to look so nice... greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
Greg KH wrote: On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote: If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. Argh! I thought the whole point of this was to make there be only one hotplug strategy, due to the fact that this is a real need. Please let's not go down this path. It was all starting to look so nice... I -want- there to be only one hotplug strategy, but Adam seemed to be talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. I'm hoping that Linus will disagree with the splintering of CONFIG_HOTPLUG too... I think it's too late in 2.4.x cycle to change now anyway. Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
On Wed, Nov 15, 2000 at 12:54:35AM -0500, Jeff Garzik wrote: I -want- there to be only one hotplug strategy, but Adam seemed to be talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. Here's Adam's proposal for CONFIG_USB_HOTPLUG: http://www.geocrawler.com/lists/3/SourceForge/2571/250/4599696/ From what I remember (and from looking at this message), all he seems to want is to redefine the __init and __initdata macros depending on a config item. There's no other grander scheme of things, right Adam? Although such a small memory savings for turning a bus whose main goal in life is to enable hot plugged devices into a fixed connection doesn't seem worth it. We are talking embedded USB hosts here, not devices. USB devices running Linux is a whole 'nother thing, which I'm just now starting to look into... Comments Adam? thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - 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.0-test11-pre4/drivers/sound/yss225.c compilefailure
Jeff Garzik wrote: "Adam J. Richter" wrote: If a programmer errs in favor of __devinit, the result is extra memory consumption under CONFIG_HOTPLUG. If a programmer errs in favor of __init, the result is a crash during hot p ug insertion. Avoiding crashes at the expensive of a pretty small amount of memory usage is the more "conservative" way to err. You suggest avoiding correctness in order to protect against dumb programmers. That path leads to Windows. No, I was saying that if you are unsure whether to use __devinit{,data} or __init{,data}, using __dev version more closely fulfulls your request that we "Please err on the conservative side." If you are sure of the correct one to use, then, of course, I am sure we all agree you should use it. Having USB hot plugging without needing to build in PCI hot plugging is useful, Of course. But CONFIG_HOTPLUG does not mean PCI hotplugging. It means any hotplug support in the kernel. That is why __devinit exists and is used in a generic fashion. Could you please cite an example or two of where __devinit is currently correctly used for a non-PCI non-USB device? I think you can skip the places in the ISA parallel port code where it is apparently being incorrectly used (where some non-hot-pluggable ISA code that could safely be freed will be retained if the kernel is compied with CONFIG_HOTPLUG). Earlier in your email, you made an argument about the development culture ("That path leads to Windows"). In that same spirit, let's not rely on bureaucratic doctrines like "But CONFIG_HOTPLUG does not mean..." and, instead, let's look at the underlying technical issues, which I believe are: 1. there is essentially no call graph dependency between the hot plugging mechanisms of different busses, 2. we agree that having USB hot plugging without needing to build in PCI hot plugging is useful. After 2.4.0, [...] we may want to explore adding __usbdevinit{,data} defines in include/linux/init.h that would be controlled by a new CONFIG_USB_HOTPLUG option, as in the patches that I posted for this to linux-usb-devel. This is not just a USB issue. Please discuss this on linux-kernel, so we can have a coherent hotplug strategy for the entire kernel. If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. s/must/should/ (since you are not changing the resulting binary) I agree that CONFIG_HOTPLUG should be renamed CONFIG_PCI_HOTPLUG and I would further like to see __devinit{,data} become __pcidevinit{,data}. Not only does this configurability have real world uses, but the clearer labelling would also make the effected code a little more self documenting as to why the code and data in question is not just __init{,data}. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - 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/