linux-kernel - Re: [RFC] libusb / in-kernel usb driver criteria

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] [day] [month] [year] [list]

Message-Id: <20080111213840.E1B9028CD74@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
Date:	Fri, 11 Jan 2008 13:38:40 -0800
From:	David Brownell <david-b@...bell.net>
To:	greg@...ah.com, 640e9920@...il.com
Cc:	xiaofanc@...il.com, stern@...land.harvard.edu,
	pmarques@...popie.com, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] libusb / in-kernel usb driver criteria

> > > So, to get the ball rolling, here are some factors that IMHO
> > > help decide in which side to implement a driver:
> > >
> > >  - if the driver ties a hardware device to an existing
> > >    in-kernel interface (network, block, serial, bluetooth,
> > >    video4linux, etc.), it should probably be implemented
> > >    in-kernel.
> > 
> > Agreed, I think this is clear.
>
> Yes, this the primary decision point, everything after this depends on
> lots of variables :)

Including a pragmatic concern:  performance requirements.

Today's usbfs-based userspace drivers don't get any zerocopy
benefits.  So if you're passing around enough data that your
target environment needs a zerocopy I/O model (maybe it's got
to run on an embedded system with a small battery and not much
spare CPU power), that can argue in favor of a kernel driver.

I don't know whether the "usbfs2" work addresses that issue.

- Dave


> Agreed.  It all depends on the situation, we have kernel drivers for
> devices that can be done in userspace, but not as cleanly or nicely, and
> so, they stay as kernel drivers.
>
> In the end, it comes down to individual cases, so let's handle them at
> that level, it's easier that way.
--
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/