All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: Andries.Brouwer@cwi.nl, aia21@cam.ac.uk
Cc: adilger@turbolabs.com, linux-kernel@vger.kernel.org,
	torvalds@transmeta.com
Subject: Re: [PATCH] Enhancement of /proc/partitions output (2.5.1-pre5)
Date: Sun, 2 Dec 2001 03:28:53 GMT	[thread overview]
Message-ID: <UTC200112020328.DAA132404.aeb@cwi.nl> (raw)

    From: Anton Altaparmakov <aia21@cam.ac.uk>

    btw. You sent a patch to fsdevel some time ago converting parts of the 
    kernel to use bytes instead of 1024 byte blocks. Have you got an 
    updated/more complete version of that?

Yes. This summer I constructed the first dozen patches or so of
a path that would step by step change the present situation into one
without the `arrays', and with proper partition handling (namely not
buried down in the drivers), and with sizes as 64-bit byte amounts etc.
You can still find them on ftp.kernel.org.
Part of this was applied to 2.4.

Now that 2.5 has opened, I started (an hour ago) moving this stuff to 2.5.
(But will be abroad next week.)


    >    And I agree with Andreas the partition type would be useful
    >     in the display, too.
    >
    >I don't.
    >
    >This type is irrelevant. It would be very bad to make it available.
    >People might start using it, and that can only cause problems.
    >Moreover, usually there is no type, and in the future that I plan
    >there will never be a type. If there is a type, *fdisk will tell you.

    I am afraid I disagree. - Type is important when a partitioned device is 
    being worked on. LDM for example needs to know the types in order to make 
    sure not to take over a non-dynamic disk by mistake / to know that it is a 
    dynamic disk.

You illustrate what I say. It is vary bad to make types available,
since they do not exist. And ignorant people might start using them.

There are lots of partitioning systems in common use. And there is
no reason why LDM or MD RAID can sit on top of a DOS partition only.
Consequently, any dependence on types here is a bug.
Moreover, DOS type partitioning is dying. It cannot describe partitions
larger than 1 or 2 TB.

    .. I.e. where several different partitions have to be combined
    in various ways to give new devices? What are your thoughts
    on this? And do you have or are you aware of any code for
    these more advanced uses of partitioned devices?

No - but things will improve fully automatically. The MD code is
terrible (seen from a kdev_t point of view) and requires a lot of
restructuring.

Andries

             reply	other threads:[~2001-12-02  3:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-02  3:28 Andries.Brouwer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-12-01 22:43 [PATCH] Enhancement of /proc/partitions output (2.5.1-pre5) Andries.Brouwer
2001-12-02  2:13 ` Anton Altaparmakov
2001-12-01 11:47 Andries.Brouwer
2001-12-01 16:07 ` Anton Altaparmakov
2001-12-01 20:51 ` Marcel J.E. Mol
2001-12-03 16:30 ` Bill Davidsen
2001-12-01 11:22 Andries.Brouwer
2001-12-01  8:30 RaúlNúñez de Arenas Coronado
2001-12-01  8:47 ` Marcus Meissner
2001-12-01 16:10 ` Anton Altaparmakov
2001-12-01  7:08 Anton Altaparmakov
2001-12-01  8:39 ` Andreas Dilger

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=UTC200112020328.DAA132404.aeb@cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=adilger@turbolabs.com \
    --cc=aia21@cam.ac.uk \
    --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.