On Sun, Aug 17, 2008 at 09:45:21PM +0200, Pavel Machek wrote:
quoted text
> On Fri 2008-09-12 09:59:47, Greg KH wrote:
> > On Fri, Sep 12, 2008 at 01:35:54AM +0200, Tejun Heo wrote:
> > > Shem Multinymous wrote:
> > > >> That reduction comes because input device supports poll and
> > > >> sysfs_notify_event() does about the same thing.  The uesrland daemon
> > > >> can just poll on a node and read data nodes when poll event on the
> > > >> node triggeres.
> > > > 
> > > > Agreed.
> > > > There's another issue with the current sysfs interface, though: hdapsd
> > > > needs to read (x,y,timestamp) tuples, whereas sysfs provides just x
> > > > and y in separate attributes which cannot be read atomically together.
> > > > We can add a sysfs file with "x y timestamp" readouts, though this is
> > > > unusual for sysfs (and certainly incompatible with hwmon).
> > > 
> > > Yes, right.  Forgot about the atomicity part altogether.  Thanks for
> > > bringing it up.
> > > 
> > > >> Unloading heads will be simple.  Just echoing timeout in ms to sysfs
> > > >> nodes, so I don't think it's a good idea to push out actual unloading
> > > >> to another process especially as fork doesn't inherit mlockall.
> > > > 
> > > > I had in mind another daemon listening for "unload now" events, so no
> > > > forking needed.
> > > > This second daemon might make sense if we push the logic of deciding
> > > > *which* disks to unload into userspace, since this logic is the same
> > > > for the ThinkPad style and the HP style.
> > > 
> > > Hmmm... I can't (yet) see the benefit of having two separate userland
> > > daemons.
> > > 
> > > >> On a related note, is there any plan to merge tp_smapi to mainline?
> > > >> It seems you put a lot of work into it and I don't really see why it
> > > >> should stay out of tree.
> > > > 
> > > > The only issue I'm aware of is finding a reasonably-named maintainer.
> > > > On the technical side, the reviews on my lkml submission of
> > > > thinkpad_ec+hdaps seemed good and all technical comments are since
> > > > addressed. The code has been stable, well-tested and packaged by major
> > > > distros for years.
> > > 
> > > Cool, can you please post the patch to the lkml and cc Greg
> > > Kroah-Hartman <gregkh@suse.de>, Andrew Morton
> > > <akpm@linux-foundation.org> and me?
> > 
> > Sorry, but no, I can't accept this code as it is coming from a "known
> > anonymous" person containing information that it is not known where it
> > came from.
> 
> So... what are you worried about?

Code created by access to specs that were not allowed to be published in
GPL form by someone who wants to remain anonymous.

Come on, we went over this the last time this came up a few years ago.
It's just not going to happen due to the legal issues involved, sorry.

If people want to get this kind of code into the tree, they can write a
new driver from scratch, based on public information on these chips.
And you will have to defend exactly where this information was found as
you can not do it by information found in this "tainted" driver, sorry,
that's not a legally viable way forward.

thanks,

greg k-h
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/