From: Greg KH <greg@kroah.com>
To: Oliver Neukum <oliver@neukum.org>
Cc: Bryan Small <code_smith@comcast.net>, Sean Young <sean@mess.org>,
Chester <fitchett@phidgets.com>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: add new USB PhidgetServo driver
Date: Thu, 29 Apr 2004 12:44:27 -0700 [thread overview]
Message-ID: <20040429194426.GA19315@kroah.com> (raw)
In-Reply-To: <200404292135.42713.oliver@neukum.org>
On Thu, Apr 29, 2004 at 09:35:42PM +0200, Oliver Neukum wrote:
> Am Donnerstag, 29. April 2004 21:16 schrieb Greg KH:
> > On Thu, Apr 29, 2004 at 09:10:21PM +0200, Oliver Neukum wrote:
> > > Am Donnerstag, 29. April 2004 20:49 schrieb Bryan Small:
> > > > The IFkit ( both 8/8/8 and 0/8/8) and the TextLCD will work nearly the
> > > > same as Sean's servo control. They will use sysfs also. They will be
> > >
> > > I don't want to spoil the party, but in which way is using sysfs in this
> > > way different from using it as a form of devfs?
> >
> > - one value per file, no char or block nodes
> > - devices can export many different files depending on their
> > needs (no ioctl crud needed.)
> > - you can use a script or libsysfs a web browser, or anything
> > else that reads directory trees and files to access the device
> > info.
> > - you can have as many devices as you want in the system, no
> > limitations on minor numbers, or anything else.
> > - no unsolvable kernel race and locking issues
> > - no horribly formatted code from a developer who is no longer
> > maintaining it.
> >
> > Shall I go on? :)
>
> Yes. You are describing a better devfs, but still devfs. Why not go
> the whole way?
{sigh} Not again. Come on Oliver... Go read the archives for why
Linus does not want us to put device nodes in sysfs.
Putting device attributes such as led colors, servo motor controls, etc,
look to be much the same idea, are much different from the traditional
block and character nodes we are used to in Unix.
Think of them as mini device specific file systems instead, mounted in a
device tree.
I don't want to discuss this again...
thanks,
greg k-h
next prev parent reply other threads:[~2004-04-29 19:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-28 18:18 [PATCH] USB: add new USB PhidgetServo driver Sean Young
2004-04-28 18:41 ` Greg KH
2004-04-29 1:59 ` Sean Young
2004-04-29 3:08 ` Greg KH
2004-04-29 2:18 ` Bryan Small
2004-04-29 3:10 ` Greg KH
2004-04-29 18:49 ` Bryan Small
2004-04-29 19:10 ` Oliver Neukum
2004-04-29 19:16 ` Greg KH
2004-04-29 19:35 ` Oliver Neukum
2004-04-29 19:44 ` Greg KH [this message]
2004-04-29 20:33 ` Oliver Neukum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040429194426.GA19315@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=code_smith@comcast.net \
--cc=fitchett@phidgets.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver@neukum.org \
--cc=sean@mess.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox