Re: CVS commit: basesrc/lib/libutil

["R.o.s.s H.a.r.v.e.y" <ross%ghs.com@localhost>]

> From: Luke Mewburn <lukem%wasabisystems.com@localhost>
>
> On Sun, Dec 09, 2001 at 11:34:57AM -0800, Jason Thorpe wrote:
> > On Sun, Dec 09, 2001 at 03:49:27PM +1100, Luke Mewburn wrote:
> > 
> >  > opendisk(3) never supported a `wildcard' "iscooked" (as you call it.)
> >  > Previously it just never enforced the BLK/CHR semantics.
> > 
> > Maybe you never understood the intent.
>
> Given that I wrote opendisk(3) in the first place, maybe I didn't...

Ahh, we know you wrote it. But from the 1.1 log:

    > revision 1.1
    > date: 1997/09/25 04:53:33;  author: lukem;  state: Exp;
    > implement opendisk(3), as discussed with Jason Thorpe

You wrote it, yes, but with Jason as the designer or one of the
designers of the interface. You know this, so you really shouldn't
give just part of the story - like you just did - misleading every
reader who doesn't run the log. (It also, by the way, was an
interface, yet received no list discussion.)

I'm at a loss to understand why you are defending a couple lines
of obscure code that broke a bunch of stuff. You've checked in
many, many lines that worked out well, why worry about a couple
that obviously didn't? Why get your ego all wrapped up in
something so minor?  You are dragging this thing out for no
reason. (See tech-userlevel for an enumeration of broken stuff.)

And in order to defend it, you have resorted to abstract arguments
referencing some hypothetical original intent, and apparently you
got that wrong, too. It wouldn't even matter if type checking was the
original intent, because it clearly doesn't work well when it does that.
Then, please feel free to restate all our arguments as "the original
spec was wrong, but was saved by a good implementation, which was just
broken".

The interface is incapable of working well with type checking,
because not all types are represented in the interface. What's much
more important: files are specifically and intentionally a superclass
in unix, so specialization as forced by the two-state iscooked
interface is actually even wrong from an abstract, programming
paradigm "type checking" point of view, never mind the practical
disaster it has been.

And in order to defend it, you have also refused to comment or
respond to 90% of the problems I have pointed out.  You have picked
nits with the phrasing of my complaints. By skimming just the
easy things in my backout proposal to comment on, it seem like you
just want to "win", and not to really discuss the impact, or make
the best decision for the little obscure subroutine that hardly
ANYONE cares about, but which IS capable of doing harm and which
HAS just broken disklabel(8), vnconfig(8), pcictl(8), other client
programs, many makefiles under src/distrib, perhaps sysinst.

It seems like you aren't taking the trouble to look at this from
the other side, but are just defending whatever you did based on
your intention to do something good. Fine, but it turned out bad.

Mostly, you just explain over and over what your intention was when
you originally checked it in or when you implemented the error-out on
2001.11.1, and sometimes you claim that the client programs are
"asking for" a specific type of device. In fact they are not, the
intentions don't matter, we knew what you were trying to do from
the beginning, we disagree with that, and we are trying to explain
to you that it didn't work out well.  Please try to avoid looping
this discussion again.

And must we discuss it until the end of time? I have work to do at my
employer, all I wanted to do was build an alpha snapshot in a few
weekend hours.  It was torched by your change so I investigated.

> >From the manual page:
>       If iscooked is non zero, the ``cooked'' partition (block device)
>       is opened, rather than the ``raw'' partition (character device).
> It then goes on to explain the rules it uses in trying various path
> combinations to successfully open a file.

That's out of context, the man page FIRST says that the path provided
is opened if it's a complete path to a file.  You changed so that
the path is NOT opened, if it doesn't agree with the way-too-limited-
for-type-checking `iscooked' parameter. Think!


> > Basically, you didn't understand what "iscooked" was used for, and you
> > changed the behavior without fully understanding the consequences.
>
> I understood what iscooked was used for. I also understood that
> opendisk(3) was being abused by some programs that wanted to take
> arguments like "pci0",iscooked=1 and have that open "/dev/pci0"
> (after trying "pci0" and "pci0d" in the current directory).
> Such programs should have been using a more general opendevice(3) API.

As you know, there IS no opendevice(3).

You have now defined every caller (there are less than 10 all total)
as one abusing the interface, so I guess you are really saying:

        * the interface is better this way
        * all the programs must use something else that we will need to write

So, then, what exactly IS the point of having opendisk(3)?  And do note
that every calling program now errors out on things that used to work.

        r.o.s.s