public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Andries.Brouwer@cwi.nl
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] 2.5.18 IDE 73
Date: Thu, 30 May 2002 00:53:53 +0200	[thread overview]
Message-ID: <3CF55C01.6080101@evision-ventures.com> (raw)
In-Reply-To: <UTC200205292340.g4TNehj03682.aeb@smtp.cwi.nl>

Andries.Brouwer@cwi.nl wrote:
>>>About scanning for partitions:
>>>Several partitioning schemes exist, and reading partition tables is not
>>>something a driver should do without getting explicit requests.
>>>For all we know the disk contents may be completely random.
>>
> 
>>You are right but the fact is right now we have to do it this way.
> 
> 
> That is OK - I just write to make sure we all agree that this must
> only be an intermediate stage. Scanning for partitions must not be
> something obscure that happens deep down in some driver.
> 
> 
>>>You should offer the list of disks seen to user space, and user space
>>>should decide which disks have to be investigated, and tell the kernel
>>>about the partitions it wants to have on these disks.
>>>That way all knowledge about partitioning, dynamic disks, disk managers
>>>and the like is removed from the kernel, and moved into partx-type code.
>>
> 
>>But there is one thing, which isn't prette about the above sheme: races
>>and atomicity of operations... Well this could be solved
>>by making the mount system call passing this information as a parameters.
>>You wouldn't even need to pass any list of disks to user land - we don't
>>do it right now.
> 
> 
> You see, some disks belong to RAIDs, some disks are in reality very
> slow objects, like compact flash cards or so, some disk have some foreign
> partitioning scheme. There can be all kinds of reasons why we do not
> want to start reading and interpreting any random disk-like device.

Ahhh... wait a moment you are the one who is responsible for
util-linux - wouldn't you care to take a bunch of patches?!

> I know that we used to do this, but it was wrong, so we must slowly move
> to a setup where we do no longer do this.
> 
> So, user space is started on a ramdisk or so, and gets parameters
> rootdev=, rootpttype=, rootpartition=, rootfstype=.
> Now it can use rootpttype to scan rootdev, find the partitions,
> find rootpartition, mount it as type rootfstype on /.
> 
> Afterwards the existence of more devices, possibly with partitions,
> becomes of interest, for example because there is a "mount -a" somewhere.
> Here userspace needs a list of available devices. Maybe /proc/partitions.

/etc/vfstab, /etc/mtab -  are conceptually just fine.

No need to inevent here. No need to do the book keeping in kernel.
passwd doesn't need /proc/users too and many people just forget that
we are still on a UNIX like system.
The only case which deserves special treatment is the parition
where / resides.


  reply	other threads:[~2002-05-29 23:52 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-29 23:40 [PATCH] 2.5.18 IDE 73 Andries.Brouwer
2002-05-29 22:53 ` Martin Dalecki [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-30 15:56 Andries.Brouwer
2002-05-30 14:43 Andries.Brouwer
2002-05-30 14:01 ` Martin Dalecki
2002-05-30 15:09   ` Rene Rebe
2002-05-31 13:25     ` Denis Vlasenko
2002-05-30 12:35 Bartlomiej Zolnierkiewicz
2002-05-30  0:19 Andries.Brouwer
2002-05-30 13:02 ` Martin Dalecki
2002-05-30 15:32   ` Alan Cox
2002-05-30 13:54     ` Martin Dalecki
2002-05-30 15:05       ` Tomas Szepe
2002-05-30 15:13       ` Rene Rebe
2002-05-30 15:39       ` Wichert Akkerman
2002-05-30 16:13       ` Alan Cox
2002-05-30 14:20         ` Martin Dalecki
2002-05-30 15:31           ` Linus Torvalds
2002-05-30 18:55             ` Martin Dalecki
2002-05-30 15:25         ` Linus Torvalds
2002-05-29 18:16 Andries.Brouwer
2002-05-29 18:07 Andries.Brouwer
2002-05-29 21:57 ` Martin Dalecki
2002-05-29 13:59 Gerald Champagne
2002-05-29 13:03 ` Martin Dalecki
2002-05-29 14:26   ` Gerald Champagne
2002-05-29 14:35   ` Russell King
2002-05-29 13:40     ` Martin Dalecki
2002-05-29 16:33   ` Vojtech Pavlik
2002-05-29 15:46     ` Martin Dalecki
2002-05-29 18:47       ` Alan Cox
2002-05-30  8:48         ` David Woodhouse
2002-05-30 12:22           ` Martin Dalecki
2002-05-29 17:55     ` Alan Cox
2002-05-29 17:01       ` Vojtech Pavlik
2002-05-29 16:05         ` Martin Dalecki
2002-05-29 17:05           ` Vojtech Pavlik
2002-05-29 18:43         ` Alan Cox
2002-05-25  2:02 Linux-2.5.18 Linus Torvalds
2002-05-29 12:11 ` [PATCH] 2.5.18 IDE 73 Martin Dalecki
2002-05-29 12:58   ` Zwane Mwaikambo
2002-05-29 12:52     ` Martin Dalecki

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=3CF55C01.6080101@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox