Re: staging driver (epl)

[Greg KH <gregkh@suse.de>]

On Tue, Jan 20, 2009 at 09:04:35AM +0300, Alexey Dobriyan wrote:
> On Mon, Jan 19, 2009 at 03:59:10PM -0800, Greg KH wrote:
> > On Tue, Jan 20, 2009 at 12:03:15AM +0300, Alexey Dobriyan wrote:
> > > Greg, can I ssh to your box to do
> > > 
> > > 	git rm -rf drivers/staging/epl
> > > 	sed -i -e '/epl/d' drivers/staging/Kconfig
> > > 	sed -i -e '/CONFIG_EPL/d' drivers/staging/Makefile
> > > 	git commit -a -m 'staging: remove epl driver'
> > > 
> > > ?
> > 
> > That might be tough for you to do, as it's in every 2.6.29-rc1 release
> > out there.  That's a lot of ssh and sed commands needed for you to do :)
> > 
> > > This driver doesn't meet even _the_ basic requirements.
> > 
> > It meets the drivers/staging/ requirements of:
> > 	- it builds
> > 	- it is self-contained
> > 	- someone is using it
> > 
> > Well, some of the stuff in drivers/staging/ don't even meet the first
> > requirement, making this one of the better drivers :)
> > 
> > > It's _full_ of hungarian notation (iRet).
> > > 
> > > It's full of typedefs.
> > > 
> > > It's full of HAL (tEplApiInstance etc).
> > > 
> > > Filenames (!) are in CamelCase.
> > > 
> > > It creates sockets from kernel for something.
> > > 
> > > It tries to interact with devfs.
> > > 
> > > It may come as surprise but you also committed real Win32 code:
> > > 
> > > 	drivers/staging/epl/EplTimeruWin32.c
> > > 	drivers/staging/epl/ShbIpc-Win32.c
> > > 
> > > Amazing, isn't it?
> > 
> > No, not at all, I commited the tarball I was given, after shoehorning it
> > into the kernel build system.
> > 
> > > Do you accept _any_ code?
> > 
> > Yes.
> > 
> > > Exactly zero entry barrier?
> > 
> > Pretty much.  Know of any other drivers that should go into here that
> > are floating around in the wild?
> > 
> > Is this a problem?
> 
> Well, yes.
> 
> Suppose someone cleanups issues mentioned and make it at least look like
> usual Linux driver.
> 
> And then it likely will turn out that driver is so misdesigned that
> it will be faster to just rewrite it.

That's fine, I have no objection to a total rewrite, that's happening
already to some drivers that are already in drivers/staging/.  When
those drivers then go into the main kernel tree, I'll instantly drop the
drivers/staging/ driver.

> Now why waste time doing cleanups when the risk that cleanups will only help
> to see it's misdesigned is so high? I can't think of a Linux person mentally
> dragging himself through issues mentioned to see the end result, it's very hard
> to read such code after reading much Linux code.

I agree, but there are companies already using this code today.  So why
not include it as it is useful to a very big group of users.  If we get
it cleaned up and working better, that even helps out more.

> > Is the drivers/staging/ area just not properly documented for people to
> > understand what is going on there and how it differs from the rest of
> > the kernel?  Should I write up something a bit more "formal"?
> 
> No, too early to write policies.

Heh, how about explainations :)

thanks,

greg k-h