login
Search
As we all discussed at the Kernel Summit this past week, I said I would create a drivers/staging directory and start throwing lots of drivers that are not of "mergable" status into it. For those not at the kernel summit, lwn.net has a summary of this session at: http://www.lwn.net/Articles/298570/ So, here's 4 patches for review/comments that show how this could be done. The first 2 patches create a TAINT_CRAP flag and set it for anything that comes from the drivers/staging/ directory. When a driver from this directory is loaded into the kernel, the user is warned, and any oops message that happens also properly shows the "bad" modules. The 3rd patch creates the drivers/staging/ directory and Kconfig entries and adds it to the build system. The 4th patch is an example of a driver that would go into this directory, along with a driver_name.README file detailing what needs to be done to this driver for cleanup/fixing, and who to contact about it. It's also in such bad shape it doesn't even build against the kernel kernel :) (I'll fix that up before submitting, all drivers should at least build properly...) So, does this all look good to everyone? Any questions/issues? Oh, I guess I should add a MAINTAINER entry for this section of the kernel, so to paraphrase Linus, I now get to be known as the "Maintainer of Crap". thanks, greg k-h --
We need to add a flag for all code that is in the drivers/staging/
directory to prevent all other kernel developers from worrying about
issues here, and to notify users that the drivers might not be as good
as they are normally used to.
Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a
TAINT flag for the support level of a kernel module in the Novell
enterprise kernel release.
This is the kernel portion of this feature, the ability for the flag to
be set needs to be done in the build process and will happen in a
follow-up patch.
Cc: Andreas Gruenbacher <agruen@suse.de>
Cc: Jeff Mahoney <jeffm@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Documentation/sysctl/kernel.txt | 1 +
include/linux/kernel.h | 1 +
kernel/module.c | 9 +++++++++
kernel/panic.c | 6 ++++--
4 files changed, 15 insertions(+), 2 deletions(-)
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -368,4 +368,5 @@ can be ORed together:
2 - A module was force loaded by insmod -f.
Set by modutils >= 2.4.9 and module-init-tools.
4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
+ 64 - A module from drivers/staging was loaded.
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -261,6 +261,7 @@ extern enum system_states {
#define TAINT_DIE (1<<7)
#define TAINT_OVERRIDDEN_ACPI_TABLE (1<<8)
#define TAINT_WARN (1<<9)
+#define TAINT_CRAP (1<<10)
extern void dump_stack(void) __cold;
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1834,6 +1834,7 @@ static noinline struct module *load_modu
Elf_Ehdr *hdr;
Elf_Shdr *sechdrs;
char *secstrings, *args, *modmagic, *strtab = NULL;
+ char *staging;
unsigned int i;
unsigned int symindex = 0;
unsigned int strindex = 0;
@@ -1989,6 +1990,14 @@ static noinline struct module *load_modu
goto free_hdr;
}
+ staging = get_modinfo(sechdrs, infoindex, "staging");
+ if ...We need to add a flag for all code that is in the drivers/staging/
directory to prevent all other kernel developers from worrying about
issues here, and to notify users that the drivers might not be as good
as they are normally used to.
Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a
TAINT flag for the support level of a kernel module in the Novell
enterprise kernel release.
This is the code that actually modifies the modules, adding the flag to
any files in the drivers/staging directory.
Cc: Andreas Gruenbacher <agruen@suse.de>
Cc: Jeff Mahoney <jeffm@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
scripts/mod/modpost.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1726,6 +1726,14 @@ static void add_header(struct buffer *b,
buf_printf(b, "};\n");
}
+void add_staging_flag(struct buffer *b, const char *name)
+{
+ static const char *staging_dir = "drivers/staging";
+
+ if (strncmp(staging_dir, name, strlen(staging_dir)) == 0)
+ buf_printf(b, "\nMODULE_INFO(staging, \"Y\");\n");
+}
+
/**
* Record CRCs for unresolved symbols
**/
@@ -2133,6 +2141,7 @@ int main(int argc, char **argv)
buf.pos = 0;
add_header(&buf, mod);
+ add_staging_flag(&buf, mod->name);
err |= add_versions(&buf, mod);
add_depends(&buf, mod, modules);
add_moddevtable(&buf, mod);
--
--
Adds the driver for the Princeton Instruments USB camera. Needs a lot of work... TODO: - make checkpatch.pl clean - coding style fixups (typedefs, etc.) - get it to build properly - audit ioctls - remove ioctls if possible - assign proper minor number - remove dbg() macro - lots of general cleanups - review locking Cc: Judd Montgomery <judd@jpilot.org> Cc: Jeff Frontz <jeff.frontz@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/staging/Kconfig | 5 drivers/staging/Makefile | 1 drivers/staging/rspiusb.README | 22 + drivers/staging/rspiusb.c | 887 +++++++++++++++++++++++++++++++++++++++++ drivers/staging/rspiusb.h | 25 + 5 files changed, 940 insertions(+) --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -23,5 +23,10 @@ menuconfig STAGING if STAGING +config USB_RSPI + tristate "Princeton Instruments USB camera support" + depends on USB + help + This driver is for the Princeton Instruments USB camera device. endif # STAGING --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -1,2 +1,3 @@ # Makefile for staging directory +obj-$(CONFIG_USB_RSPI) += rspiusb.o --- /dev/null +++ b/drivers/staging/rspiusb.c @@ -0,0 +1,887 @@ +/* + * rspiusb.c + * + * Copyright (C) 2005, 2006 Princeton Instruments + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation version 2 of the License + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA ...
This hooks up the drivers/staging directory to the build system Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/Kconfig | 2 ++ drivers/Makefile | 1 + drivers/staging/Kconfig | 27 +++++++++++++++++++++++++++ drivers/staging/Makefile | 2 ++ 4 files changed, 32 insertions(+) --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -101,4 +101,6 @@ source "drivers/auxdisplay/Kconfig" source "drivers/uio/Kconfig" source "drivers/xen/Kconfig" + +source "drivers/staging/Kconfig" endmenu --- a/drivers/Makefile +++ b/drivers/Makefile @@ -99,3 +99,4 @@ obj-$(CONFIG_OF) += of/ obj-$(CONFIG_SSB) += ssb/ obj-$(CONFIG_VIRTIO) += virtio/ obj-$(CONFIG_REGULATOR) += regulator/ +obj-$(CONFIG_STAGING) += staging/ --- /dev/null +++ b/drivers/staging/Kconfig @@ -0,0 +1,27 @@ +menuconfig STAGING + bool "Staging drivers" + default n + ---help--- + This option allows you to select a number of drivers that are + not of the "normal" Linux kernel quality level. These drivers + are placed here in order to get a wider audience for use of + them. Please note that these drivers are under heavy + development, may or may not work, and may contain userspace + interfaces that most likely will be changed in the near + future. + + Using any of these drivers will taint your kernel which might + affect support options from both the community, and various + commercial support orginizations. + + If you wish to work on these drivers, to help improve them, or + to report problems you have with them, please see the + driver_name.README file in the drivers/staging/ directory to + see what needs to be worked on, and who to contact. + + If in doubt, say N here. + +if STAGING + + +endif # STAGING --- /dev/null +++ b/drivers/staging/Makefile @@ -0,0 +1,2 @@ +# Makefile for staging directory + -- --
I sure hope this does not end up like EXPERIMENTAL although it essentially does duplicate the intent of EXPERIMENTAL. (In other words - drivers live there for ever in staging mode, we print warnings and generally nobody cares about the problem since the kernel is tainted.) That aside please at least substitute the word CRAP with something better - like TAINT_NON_PRODUCTION or TAINT_UNRELIABLE or TAINT_WORK_IN_PROGRESS or TAINT_EXPERIMENTAL . Arguably TAINT_EXPERIMENTAL could also be used for known broken CONFIG_EXPERIMENTAL items. It might also be better to change the staging directory name to non-production or experimental - but that's just my preference. Also, I suppose it would be useful for Production machines to have a kernel command line flag or something to say don't load staging modules - for instance to prevent against automatic loading on drivers from staging directory to support some oddball device etc. Thinking more about it - could this whole thing not be achieved by setting per module experimental flag and refusing to insmod'ing experimental modules if -f was not specified. I believe force loading also taints the kernel? All drivers intended for staging can set that flag - this way we don't need another TAINT flag and there is no need for the directory name hack. Parag --
Thanks. I agree with Parag's comments. Looks like overkill/duplication. --- ~Randy --
I disagree, see my response to Parag's comments :) thanks, greg k-h --
No, this is much different from EXPERIMENTAL. That flag is pretty much useless right now. This is for a temporary landing place for drivers that are not good enough to be merged, yet are useful enough for some people to use. Examples of this is the USB driver I posted, some network drivers that are in -staging that only work on x86 boxes, and drivers that have userspace interfaces that are "wrong" and need to be changed (reading files from /etc is one example.) All of those types of drivers are not capable of being merged today, and EXPERIMENTAL doesn't mean anything there. Also, api changes do not have to propagate into the drivers/staging/ directory. I'll work to keep up with them, keeping everything working properly, just like I have been with the external -staging tree. This is just pushing it into the tree to give it much wider exposure and draw from more developers makeing it easier to give them the proper credit Why, that word is only internal, nothing outside of the kernel sees that flag at all, no user will ever know this. And if we leave it as TAINT_CRAP, and a developer sees it, perhaps it I can easily add a "no_crap" flag to the command line. Oops, there's This keeps these kinds of drivers in one place, obvious to all that work needs to be done, and userspace interfaces can, and usually will change for such drivers. I think the boat has left on making EXPERIMENTAL mean anything anymore, but if you or anyone else wants to clean up the tree, and free it up, then I would reconsider using it here instead. But you can't start making it something that means more than it does today, as I can easily see that breaking systems that currently rely on those drivers. thanks, greg k-h --
How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and CONFIG_EXPERIMENTAL are no different - neither to users nor to developers. Here is why - Both try to do the same thing - let people use the drivers on their own risk (as if the stable ones are developer's risk - but let's keep it aside for the moment) and give developers a chance to keep the code in sync with mainline and improve it per user problem reports or generally make it better. You might try to differentiate between them on the basis of relative brokenness or crappiness if you will - but it is essentially the same - code that is not ideal for merge in mainline, code that needs user testing to trash out problems, and code that need to be in sync with mainline and code that users want to use in order to be able to use I don't see a reason to further classify and label the experimental Sure. Merge them under EXPERIMENTAL - may be with a big fat colored KConfig warning about what is broken. Tainting and labeling it staging does nothing of any value add. Sure you can have a staging directory in the tree and dump all the unmergeable code there if that gives a sense of isolation but I do not see a point in letting users build the staging code, loading it without their intervention and then printing a warning and tainting the kernel. So what if there is a oops report tomorrow and we know it is Tainted : EXPERIMENTAL - OOPS reports generally are very indicative of where the problem is coming from and the knowledge that certain broken driver is loaded is just fine to be outside the kernel - no need for the TAINT intimidation which drives away users from reporting it and There's the clue - this _will_ happen with staging - I can almost see it. So why not do it under one existing monster of an umbrella - or do you have plans to make sure you are not going to add a new staging driver unless the existing ones graduate to stable? Even if you do - doable under EXPERIMENTAL. Parag --
Sorry, no, the EXPERIMENTAL horse has left the barn. If you want to run after it and round it up and bring it back, that's great, but that is Again, no, the current EXPERMENTAL marking is pointless and a mess. If It provides a fast way into the kernel for companies who do not stick around to take the time to merge things in. That's what the -staging tree has been doing quite well for the past 6 months or so, with lots of drivers moving into mainline, and 15 drivers currently residing in it. This is moving that tree into the kernel to provide all of the reasons I But I sure want to show such a marking, don't you? It isn't costing anything, and if a developer doesn't want to debug the kernel if such a driver is loaded, this allows them to do this. It was a requirement No, it will not happen, the code is self-contained in a sub-directory, with an active maintainer, and lots of active helper developers (as have been sending me patches over the past weeks.) If this does happen, and drivers/staging/ grows to be a large dumping ground with no movement out of it, then I'll worry about that then. But I really don't think it will happen. thanks, greg k-h --
The whole concept is a bike shed - disproportionate importance to labeling same things with different name. So it should come as no surprise that we are discussing the need for Again - sure move the staging directory to the mainline tree, group all those drivers under CONFIG_HALFBAKED and default the whole category to N. Name those driver modules with a _stg prefix and be done with it. No need for the insanely useless module loading crap because - 1) You will happily load from that directory automatically if device is present - user wants it or not 2) You want users to test it and report bugs and still warn them and taint their kernel so any problems can be ignored. 3) OOPS reports are generally specific enough to identify the peripheral driver was a culprit or not - TAINTING does not achieve anything significant apart from intimidation and completely redundant I am not sure why _anyone_ would want to since it serves nothing. I will ask it again - If you do not want to use EXPERIMENTAL - fine. How about you remove the TAINT crap and do this instead - 1) Give a staging directory for all such low quality crap 2) Give a KConfig group "Staging Drivers (Low Quality/High Risk)" and if that is selected allow users to individually select the crappy drivers they want to actually use - default all entries to N 3) Name all modules under staging with a _stg suffix or something unique 4) By default do NOT load anything with a _stg suffix - deal with this in insmod code, not the kernel 5) Require that -f be specified to load _stg modules - which will auto-taint the kernel That will allow you to do what you want without touching kernel code - OOPS report, just look for _stg and decided whether or not to pursue That is good to hear - we will see :) Thanks! Parag --
Heh, ok, so the basic premise of getting code that is not currently in mergable shape into the tree earlier to get wider usage and testing is something that you agree with? If so, we can arm-wrestle over what to call it, one name is as good as another, as long as we don't overload a currently used name like EXPERIMENTAL, which Paul has so well explained is a mess right now. And I don't have the inclination to clean up that mess right now, I'm more worried about bigger messes like these 15 horrible drivers I'm currently sitting on in -staging. If not, please let me know your objections. thanks, greg "green! The bikeshed must be green!" k-h --
I don't think I got my point across - let me try again. My disagreement was with getting crap code in mainline, re-classifying it as something other than experimental when it is not, expecting users to use it, printing warning when it is used, tainting the kernel for even more harassment and then having developers not support it as a bonus - all cumulative. The naming part was also something that I did not like but that like I said was just my preference and does not matter because I disagree there is no need to TAINT in first place. I can imagine that getting crap code in mainline is helpful for some class of users and developers - no problem we can have it in on that basis - I give up my objection there. But my objections to the other parts remain - i.e. we should definitely avoid the useless re-classification and TAINT, we should change little or no other kernel code in the process of integrating this crap, give enough deterrent for people to really think before loading the crap code, and do not make it an official statement that you will get no support on LKML if you load this driver. Because certainly not all developers agree and we by definition of this staging effort have an interest in fixing the code. The below approach I referred few times earlier will allow us to do exactly that - it would be good if you can tell me if this is workable. 1) Give a staging directory for all such low quality crap 2) Give a KConfig group "Staging Drivers (Low Quality/High Risk)" and if that is selected allow users to individually select the crappy drivers they want to actually use - default all entries to N 3) Name all modules under staging with a _stg suffix or something unique 4) By default do NOT load anything with a _stg suffix - deal with this in insmod code, not the kernel 5) Require that -f be specified to load _stg modules - which will auto-taint the kernel and developers can decide on their judgment / situation whether or not to pursue it 6) OOPS reports with ...
I'm sorry we disagree here. Also note that this goes against what a number of us decided at the kernel summit, we want this code into the So you now agree with the idea, just the implementation of the area A name doesn't really matter here, the modinfo tag is just as Um, no, I'm not going to force all userspace users to upgrade their version of module-init-tools, JUST to prevent them from automatically So you have to load the modules by "hand"? Ick, no, that too is not acceptable as it means no one will ever do it. Don't break the wonderful infrastructure we already have around the kernel of auto-loading the proper driver for the proper hardware just because you My patch set already does this, and it does so in a way that uniquely distinguishes from the -f option, which some of us don't want to debug What's the objection for the 9 extra lines in module.c, 2 lines in panic.c, and 9 lines on scripts/mod/modpost.c? Is this some huge overhead that is unmaintainable? Heck, the insmod changes would be more than that I imagine (and it would be in modprobe, not insmod, it has to do with alias matching and that No, I really think it isn't more than that. For some reason you are afraid of another taint flag, why? There is no extra overhead, and no user needs to upgrade any userspace component at all (which, if you have any experience with, you will know it just will not happen fast, if at all for the large majority of users/developers.) I don't want to make the kernel require a new version of module-init-tools, and my current proposal of infrastructure changes requires a massive core change of: Documentation/sysctl/kernel.txt | 1 + include/linux/kernel.h | 1 + kernel/module.c | 9 +++++++++ kernel/panic.c | 6 ++++-- scripts/mod/modpost.c | 9 +++++++++ 5 files changed, 24 insertions(+), 2 deletions(-) How much smaller do you expect this to get? thanks, greg k-h --
You don't tell me why you want to do something as absurd and incoherent as wanting users to load the modules easily and automatically, then printing a warning about it even when user may not have loaded it on his/her own, then taint the kernel when there is no need to - I have repeatedly said it is very easy to see from the module list for people to decide - not rocket science, definitely not for developers. The whole TAINT drama is unnecessary. Why would people run with even 24 more lines for something as absurd as this when there is no need for the same? Sure if you want to autoload modules on users back - do not complain about it, do not make it official that it won't be supported since if you do all your staging drivers are even more likely to stay there like EXPERIMENTAL. (i.e. take out the printk , take out the TAINT) - then it sounds less absurd. Parag --
It _is_ necessary. I for one don't want to have to remember that driver foobar was in "staging" state in kernel 2.6.31-rc5, but not anymore in 2.6.32-rc1. -- Stefan Richter -=====-==--- =--= ==-=- http://arcgraph.de/sr/ --
On Fri, Sep 26, 2008 at 2:36 PM, Stefan Richter Just name the staging modules with _stg prefix like I said - easier to spot _stg in the module list than decoding the taint. Whenever (doubtful tone here) it graduates, remove the suffix. Driver modules load automatically any way so the name change is not going to make a difference. It is nice to not have to change core kernel code and annoy users with warnings for the staging crap even if it is just 24 lines or whatever - if we can - and I don't see why we cannot. Staging, just like crapping, has to be a totally isolated, zero side effect, zero annoyance (to others) type thing :) So let's please get rid of that taint and warning already :) Parag --
Um, it's the same, the taint is decoded automatically for you, no need to strain any brain cells trying to figure it out :) If people really want a prefix, sure, I have no objection, that's simple No, that was one of the requirements that came out of the discussions at the kernel summit, I'm going to leave both the warning and the modalias and taint flag there, sorry. If you really don't like it, just never enable any of these modules, you'll never be bothered by it. thanks, greg k-h --
So you are saying if a distro ships allmodconfig kernels or ships the crap modules in the hope that people will find them useful and I have one of the devices in my machine that I don't care about - I should just let the crap module autoload and crash/taint my kernel or take the special step of blacklisting all of them or build my own kernel - as unreasonable as ever. Or are you saying distros should not build the crap modules - that doesn't make sense since it will drastically reduce the usage and delay the identification of problems until later. If they weren't loaded automatically - it will simplify things a lot - people with those devices willing to use those modules can forcibly load the ones they require - that gives you your beloved TAINT and avoids any core kernel changes. No offense but I don't think is helping Greg. So I will stop. Parag --
If your distro does this, then they will have their own rules in place for supporting this. Take it up with them if they decide to enable I'm saying distros need to evaluate this based on their own usage / support model, just like they do so for all other config options. As an example, for a distro that I know a bit about, I can see openSUSE enabling this option and supporting these drivers the best that they can, but for the SLES product line, which doesn't even load any modules that are not fully L3 supported, these drivers would not be included. As others have raised, the issue, I'll leave the driver names alone, it would just confuse people even more if they changed, the modalias flag is good enough to mark them by for now. thanks, greg k-h --
Hello, I would like new drivers for new devices to live into the wild. Seriously, I think it's a good think to have new drivers lift along with the kernel source distribution to get *much* wider attention, testing, hacking and feedback. I propose GREG_GOES_WILD and I will happily commit my driver-in-progress to the kernel staging areas instead of to some two-people-know-about-it-location. Thanks for the effort, Greg, Regards, -- Leon --
Great, send them on over, I am already starting to queue them up (have 3 network drivers and one USB drivers in the tree, with more to come.) thanks, greg k-h --
On Fri, Sep 26, 2008 at 4:39 PM, Stefan Richter So people now a days crave for documenting staging modules and also get confused by the mixed use of driver_stg or driver? Come on. The name changes hardly matter for auto loading staging modules and I would be surprised if people document crap modules especially since the stable ones are documented later if at all they end up being documented. Parag --
Many of the staging drivers are already in active use; one or another even for years. Since they are not as easy to use as mainline drivers, people discuss and document them. -- Stefan Richter -=====-==--- =--= ==-== http://arcgraph.de/sr/ --
Uhm.. not quite. As the one that proposed the flag in the first place, perhaps it helps to cover the rationale (although Greg seems to have mostly covered that already). EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in practice is that somethings needs some more testing, someone wants to be able to pull out the EXPERIMENTAL card when someone enables their option and their kernel blows up, the option/feature hasn't been around in the kernel for that long, or someone has just been too lazy to remove the flag (this last one probably covers about 90% of in-tree cases today). Stuff that is actively broken (in case of your kernel blowing up, not building, etc.) tends to be shoved under BROKEN instead. Case in point: $ find arch | grep _defconfig | wc -l 336 $ find arch | grep _defconfig | xargs grep 'CONFIG_EXPERIMENTAL=y' | wc -l 324 $ find arch | grep _defconfig | xargs grep 'CONFIG_BROKEN=y' | wc -l 0 So given that, CONFIG_EXPERIMENTAL is something that's almost universally enabled, and has precisely _zero_ meaning. As others have mentioned in the past, it would be nice to try and audit each one of the EXPERIMENTAL users and try to get things under control a bit, so we can get back to a point where it actually means something, but we're definitely nowhere near that point today. Now, TAINT_CRAP (other options were TAINT_INCOMPETENT_VENDOR and TAINT_GREG). This is something with a completely different meaning. staging/ drivers are there because there are users for these devices, and we actively want people looking at and cleaning up this code. As is evident by other proprietary driver usage statistics, it's evident that users will generally pick device functionality (whether perceived or otherwise) over system stability quite a lot of the time. The stuff in this directory is by no means ready to be merged with the rest of the kernel, and is generally in pretty rough shape. While these drivers are generally audited to make sure they are not ...
then it would be better if Greg/someone cleaned up the current tree's problems instead of introducing more CRAP under a different name. Oh well, his mind is already made up and I know how difficult it is to --- ~Randy --
I shouldn't have said that last sentence. I apologize to Greg. ISTM that the real problems are (a) it's easier to introduce new staging/crap than it is to fix EXPERIMENTAL and (b) no one wants to try to fix EXPERIMENTAL. --- ~Randy --
Heh, no problem, normally my problem is that I change my mind too often, The whole EXPERIMENTAL issue hasn't come up in years, I'm supprised that people even consider it a valid option these days. I'm all for fixing it up, but as Paul so well described, the code I'm talking about is WAY worse than a mere "experimental" marking, it needs to be explicitly pointed out that this is not even up to that level at all. And as was also pointed out, the EXPERIMENTAL marking cleanup is totally orthogonal to the main goal here, and that is getting code into the tree that is not up to our "normal" merge quality levels, in order to get a wider audience of users and developers working on it, and using it. Hey, if people want me to name it TAINT_GREGKH, I can do that, I thought I was being nice by picking TAINT_CRAP... thanks, greg k-h --
I don't disagree with the CRAP name... fwiw. I think that we have enough quality problems without adding crap. -- ~Randy --
True. OTOH many if not most of the -staging drivers are ones which are already in use. Their users already deal with whatever quality problems these drivers have, in addition to having to fight with the installation hassles that are inherent to out-of-tree drivers. -- Stefan Richter -=====-==--- =--= ==--= http://arcgraph.de/sr/ --
I do believe that staging != experimental. experimental == 'good enough code architecture-wise, needs more testing, coding style is ok' staging == 'don't look at this after lunch' (at least parts are bad). Now... I guess someone could go over supported drivers in enterprise distro, and remove experimental from all of them in mainline...? Distros pay some attetion to what code they are willing to support... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --
Sorry for being late in the discussion, I'm currently catching up with
my email backlog.
What does that mean in practice for kernel development?
Will breaking crap be considered OK?
As an example, let's assume some crap drivers use the BKL in a way that
it might require the BKL in some core part of the kernel. Will the
person removing the BKL in the core part of the kernel be forced to fix
the locking of all possibly affected crap drivers no matter how broken
and undocumented it is, or can he simply ignore the crap and leave the
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
He can ignore the crap and leave the fixing to the Maintainer of Crap. Although a short note to the Maintainer of Crap about the crap that needs fixing in the tree of crap, would be polite, it is not required. thanks, greg "surrounded by crap" k-h --
On Fri, 10 Oct 2008 00:01:37 +0300 <collapses in a hysterical seizure> Every development tree right now will go out and breezily break random other development trees with nary a care in the world. What difference does one more tree make? --
