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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox