Future of RAIDFrame and Vinum

[M. Warner Losh]

In message: <200401120341.42349.linimon at lonesome.com>
            Mark Linimon <linimon at lonesome.com> writes:
: > If nothing happens, vinum is going to break even more very soon.
: 
: No ... if you do a commit that changes the code assumptions upon
: which vinum was built, vinum will break.  vinum is not going to
: "magically" break by itself.

Another way of looking at it is that vinum failed to keep up.  There
are many other examples that this has happened to.  FreeBSD is a
dynamic system, full of life and vigor.  Some parts of it are more
vigorous than other parts.  There's a boatload of ISA drivers that are
about to be desupported because they rely on old interfaces.  There's
a number of pci devices that have already been removed because they
couldn't keep up.  And before that, there were a number of pccard
drivers that broke when we went to newbus.

: But, in the real world of software engineering, He Who Breaketh It,
: Must Fixeth It.

That's not always a viable option.  We've obsoleted a number of
drivers over time because the developers that were moving the rest of
the system forward just flat didn't have the hardware to properly test
changes.  Also, there's a fuzzy core of FreeBSD that 'everybody' cares
about and makes sure keeps working.  The further you get from that
core, the harder it is to keep things working.  Fewer people deal with
the code and changes to the rest of the system may impact that to a
larger or smaller degree.  It is up to the 'fringe' folks to keep the
'fringe' code in shape.  There's simply too much in the tree to expect
otherwise.

Put another way, would you expect me to order European ISDN service
while I live in the US, and find ISDN hardware when I'm doing some
wide ranging change that brushes up against i4b?  Or should I get an
OS/2 system online if I happened to have a change that could impact
hpfs?  Or should I fix an ISA driver that literally no one is using?

The reality of the situation is that there has always been a balance
between moving forward and keeping compatibility.  We've come out of a
period where not too many things have forced a break with
compatibility.  As a result, we've got a lot of ugly architectural
code in the tree.  We're now moving into a period where those things
will be cleaned up.

It will continue to be a balancing act moving forward.  It is better
to identify the colater damage up front than to be meek about it.
That's why phk's saying something about vinum.  It is in the
uncomfortable middle ground.  Clearly it is useful to a lot of
people.  However, it is equally clear that it hasn't had the care and
feeding that other parts of the system have had and this neglect is
starting to show.  If this were some obscure file system (say amiga
DOS file system), then it would be easy to make the tradeoff.  If it
were used on every box it would also be easy (eg UFS).  Since it is in
the middle ground, it becomes a painful decision: it is too much for
one person to do in addition to the needful cleanups, and it is too
important to just ignore.

Warner