From: Greg KH <greg@kroah.com>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: Patrick Mansfield <patmans@us.ibm.com>,
James Bottomley <James.Bottomley@steeleye.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BK PATCH] SCSI update for 2.6.3
Date: Tue, 24 Feb 2004 14:09:46 -0800 [thread overview]
Message-ID: <20040224220946.GA2389@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0402242028370.3713@kai.makisara.local>
On Tue, Feb 24, 2004 at 11:48:32PM +0200, Kai Makisara wrote:
> On Tue, 24 Feb 2004, Patrick Mansfield wrote:
>
> ...
> > Current 2.6 kernel default names are of the form: st[0-9]m[0-3][n]
> >
> Actually more like st[0-9]*m[0-9]*[n]
>
> > Current /dev naming is of the form: [n]st[0-9][alm]
> >
> Depends on who's /dev you are looking at.
How about everyone look at devices.txt as that is the LSB standard.
> > Should the st kernel names be changed to map to current /dev names?
> >
> I don't think we should go back to the old names. The intention with the
> "new" names was to make them easier to parse and handle than the old ones.
> The number of modes is not always four. Anyone can compile st with more or
> less modes. Using a number for the mode is naturally extensible. The
> characters at the end of the old names had interpretations that may not be
> correct in all cases (a=alternate, l=low density, m=medium density).
>
> n has been put at the end of the name because now the tape names are
> grouped together in a listing. I know this is a weak justification ;-)
>
> > For udev, even with that we need differing pre and postfix values wrapped
> > around a peristent name.
> >
> If I read udev correctly, it can now parse one number at the end of the
> name. Something like st%md%n and nst%md%n could be used with eight rules
> (where %m is the mode number and %n is the device number). Not very
> convenient. Parsing the st names should really be able to extract at
> least two fields. With an external program, anything can be done. Maybe
> udev can some day do this internally.
Well, udev didn't think that anyone would do such a looney thing in
nameing devices :)
But yes, I'll be glad to fix up udev if you all fix up the tape sysfs
names to match device.txt.
thanks,
greg k-h
next prev parent reply other threads:[~2004-02-24 22:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-24 7:30 [BK PATCH] SCSI update for 2.6.3 Kai Makisara
2004-02-24 7:30 ` Kai Makisara
2004-02-24 17:04 ` Greg KH
2004-02-24 17:04 ` Greg KH
2004-02-24 17:08 ` James Bottomley
2004-02-24 17:16 ` Greg KH
2004-02-24 17:33 ` Linus Torvalds
2004-02-24 17:51 ` Kai Makisara
2004-02-24 17:55 ` Greg KH
2004-02-24 18:15 ` Patrick Mansfield
2004-02-24 21:41 ` Greg KH
2004-02-24 21:48 ` Kai Makisara
2004-02-24 22:09 ` Greg KH [this message]
2004-02-24 22:32 ` Kai Makisara
-- strict thread matches above, loose matches on Subject: below --
2004-02-25 16:46 Moore, Eric Dean
2004-02-25 20:17 ` Joe Korty
2004-02-25 0:23 Moore, Eric Dean
2004-02-25 14:29 ` Joe Korty
2004-02-24 4:24 James Bottomley
2004-02-24 4:24 ` James Bottomley
2004-02-24 4:52 ` Linus Torvalds
2004-02-24 4:52 ` Linus Torvalds
2004-02-24 15:24 ` Joe Korty
2004-02-24 15:34 ` James Bottomley
2004-02-24 16:04 ` Joe Korty
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=20040224220946.GA2389@kroah.com \
--to=greg@kroah.com \
--cc=James.Bottomley@steeleye.com \
--cc=Kai.Makisara@kolumbus.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=patmans@us.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.