LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Andries Brouwer <aebr@win.tue.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: rfc: test whether a device has a partition table
Date: Wed, 24 Sep 2003 17:18:15 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0309241710380.1688-100000@home.osdl.org> (raw)
In-Reply-To: <20030924235041.GA21416@win.tue.nl>


On Thu, 25 Sep 2003, Andries Brouwer wrote:
> 
> Ha, Linus - didn't you know I am always right?

Yeah, sure. But ...

> But being right in theory - like you say, I have repeated these
> things for many years - is not enough to submit a kernel patch.
> The post of today was prompted by a mail about
> certain USB devices:
> 
> > On closer examination it seems to be the partition table
> > which is read ok (as one partition) on W2K and XP
> > but Linux (both 2.4 and 2.6) gets really confused and
> > thinks there are 4 malformed partitions.

So? There's a bug, and we'll fix it. 

The _worst_ thing that can happen is that you have four extra (totally 
bogus) partitions, and you end up using the whole device.

That's my point about partitioning - not that it's necessarily perfect, 
but even when it _isn't_ perfect, it's no worse than not partitioning at 
all.

I know you don't want the kernel to partition at all. But I don't see your 
point. 

> > Linux probably needs to handle this situation more
> > gracefully. A local police force bought a bunch of
> > these devices for Linux based forensic work. They
> > are a bit disappointed at the moment.
> 
> So, now not only theory but also practice is involved, and
> we must do something.

Why don't they just read the whole device, if that is what they want to
do?

So we have two cases:
 a) we have a bug in the partitioning code, and don't parse the partition 
    table right:
	- let's fix the bug
 b) people don't want to read the partition info at all, as it's bogus
	- use the whole-device node.

In neither case is your "the kernel shouldn't guess" argument the answer, 
as far as I can see. And in both cases you _can_ fix it up in user mode if 
you know how, so clearly the kernel was no worse off guessing.

		Linus


  parent reply	other threads:[~2003-09-25  0:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-24 20:29 Andries.Brouwer
2003-09-24 21:54 ` Linus Torvalds
2003-09-24 23:50   ` Andries Brouwer
2003-09-25  0:05     ` viro
2003-09-25 12:14       ` Andries Brouwer
2003-09-25  0:18     ` Linus Torvalds [this message]
2003-09-25  6:53       ` Xavier Bestel
2003-09-25 10:57       ` Andries Brouwer
2003-09-25  4:47     ` Linus Torvalds
2003-09-25  4:56       ` Linus Torvalds
2003-09-25 11:42       ` Andries Brouwer
2003-10-05  9:00   ` Meelis Roos
2003-09-25  0:42 ` Douglas Gilbert
2003-09-25  1:00   ` viro
2003-09-25  1:27     ` Douglas Gilbert
2004-05-22 11:18 Uwe Bonnes
2004-05-22 12:37 ` John Bradford
2004-05-22 12:56 ` Andries Brouwer
2004-05-22 15:14   ` Uwe Bonnes

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=Pine.LNX.4.44.0309241710380.1688-100000@home.osdl.org \
    --to=torvalds@osdl.org \
    --cc=aebr@win.tue.nl \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: rfc: test whether a device has a partition table' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).