lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090120060435.GA3421@x200.localdomain>
Date:	Tue, 20 Jan 2009 09:04:35 +0300
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Greg KH <gregkh@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: staging driver (epl)

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ