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.
next prev parent 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 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.