staging driver (epl)

staging driver (epl)

[Alexey Dobriyan]

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'

?

This driver doesn't meet even _the_ basic requirements.

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?

Do you accept _any_ code? Exactly zero entry barrier?

Re: staging driver (epl)

[Greg KH]

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?

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"?

thanks,

greg k-h

Re: staging driver (epl)

[Alexey Dobriyan]

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.

I'm very certain this will happen because it's a Windows 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.

> 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.

Re: staging driver (epl)

[Greg KH]

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