mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: bcrl@redhat.com, phillips@bonn-fries.net
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	torvalds@transmeta.com, viro@math.psu.edu
Subject: Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
Date: Mon, 21 May 2001 14:43:06 +0200 (MET DST)	[thread overview]
Message-ID: <UTC200105211243.OAA62469.aeb@vlet.cwi.nl> (raw)


    How about:

      # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap
      # ls /dev/mypartition
      base    size    device    type

    Generally, we shouldn't care which order the kernel enumerates
    devices in or which device number gets assigned internally.  If we
    did need to care, we'd just do:

      # echo 666 >/dev/mypartition/number

Only a single thing is of interest.
What is the communication between user space and kernel
that transports device identities?

Note that there is user (human) / user space (programs) / kernel.

This user has interesting machinery in his hands,
but his programs have only strings (path names, fake or not)
to give to the kernel in open() and mount() calls.

Now the device path is so complicated that the user is unable to
describe it using a path name. devfs made an attempt listing controller,
lun, etc etc but /dev/ide/host0/bus1/target1/lun0/disc is not very
attractive, and things only get worse.

When I go to a bookshop to buy a book, I can do so without specifying
all of Author, Editors, Title, Publisher, Date, ISBN, nr of pages, ...
A few items suffice. Often the Title alone will do.

We want an interface where the kernel exports what it has to offer
and the user can pick. Yes, that Zip drive - never mind the bus.
But can distinguish - Yes, that USB Zip drive, not the one
on the parallel port.

The five minute hack would number devices 1, 2, 3 in order of detection,
offer the detection message in /devices/<nr>/detectionmessage
and a corresponding device node in /devices/<nr>/devicenode.
The sysadmin figures out what is what, makes a collection of
symlinks with his favorite names, and everybody is happy.

Until the next reboot. Or until device removal and addition.
There must be a way to give permanence to an association
between name and device. Symlinks into a virtual filesystem
like /devices are not good enough. Turning the five minute
hack into a ten minute hack we take the md5sum of the part
of the bootmessage that is expected to be the same the next time
we encounter this device and use that as device number.

I think a system somewhat in this style could be made to work well.

Andries

             reply	other threads:[~2001-05-21 12:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-21 12:43 Andries.Brouwer [this message]
2001-05-21 16:08 ` Daniel Phillips
  -- strict thread matches above, loose matches on Subject: below --
2001-05-22 18:45 Andries.Brouwer
2001-05-19 11:09 Andries.Brouwer
2001-05-19 11:43 ` Andrew Morton
2001-05-19 12:00   ` Alexander Viro
2001-05-19 15:56     ` Ben LaHaise
2001-05-19  6:23 Ben LaHaise
2001-05-19  9:42 ` Christer Weinigel
2001-05-19  9:51 ` Christer Weinigel
2001-05-19 11:37 ` Eric W. Biederman
2001-05-19 14:25   ` Daniel Phillips
2001-05-21  8:14     ` Lars Marowsky-Bree
2001-05-22  9:07       ` Daniel Phillips
2001-05-19 13:53 ` Daniel Phillips
2001-05-19 18:31 ` Linus Torvalds

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=UTC200105211243.OAA62469.aeb@vlet.cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=bcrl@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@bonn-fries.net \
    --cc=torvalds@transmeta.com \
    --cc=viro@math.psu.edu \
    /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

all inboxes | Powered by JetHome®