Subject: Re: bounds checking RAW_PART [was: Re: CVS commit: src/sys/dev]
To: None <tech-kern@netbsd.org>
From: Christoph Badura <bad@bsd.de>
List: tech-kern
Date: 02/03/2003 21:04:29
Sorry for the delay.

On Sun, Jan 26, 2003 at 04:21:07PM -0800, Jason R Thorpe wrote:
> On Mon, Jan 27, 2003 at 01:15:39AM +0100, Christoph Badura wrote:

> I have no problem with bounds-checking RAW_PART.  But it should not be
> done with bound_check_with_label().  That function is desinged to bounds-
> check against the disklabel.  RAW_PART is not to be checked against the
> disklabel.  That is my only objection.

Well, I have thought about that before.  If you actually go and implement
that you end up duplicating most of the innards of bounds_check_with_label().
You also need to add a user land utility to set the bounds in the rare cases
where they get initialised to the wrong value by the drivers and you have
to add a new ioctl case to the drivers to handle setting the bounds.

After you're done with all the above you gotta ask yourself to what value
the bounds will be set in almost all cases.  Judging from my experience it
will be the same value as the one in the disklabel. IMO that's a lot of
redundancy for no apparent effect.  (And in my book we get extra minus points
for having grown a twisty little maze of some 40 bounds_check_with_label()s
all slightly different. I don't think we want to repeat that experience with
a number of bounds_check_raw_part()s.)

In the few cases where one actually wants different bounds than what is stored
in the disklabel, I think updating the in-core disklabel is not too severe
a constraint.  Of course, disklabel(8) isn't very cooperative here as it
always wants to update the on-disk disklabel too.  That's something that's
bugged me a couple of times and made me want to add a flag to disklabel(8)
to just update the in-core label and not the on-disk one too.  That would
have come in really handy a couple of times.

--chris