I think you are a little out of order here. Drivers that don't affect other
code areas have always been added, some were added in 1.2.x as well. Look at
it logically if you say N as before your kernel is the same if you say Y
then you probably have one and before you were totally screwed.
The bridging fix for example changes only experimental code and I actually
diffed the objdump of the networking code tree with bridging off to prove
no overlap
> We've even been adding code into the 2.0 releases (the merging in of the
> FreeBSD NCR53c810 driver, which hasn't worked for me and a number of
> friends, for starters) - a release that, according to the various FAQ's &
But if the old driver worked for you it had no affect. If the old driver didnt
it might have saved your butt.
> Let's try to make the 2.0/2.1 series more like the 1.0/1.1 series, and
> less like the 1.2/1.3. We're already at 2.0.10; that alone makes me
> worry about the true stability of this release.
>From the experience of folks running it in many areas of use its more stable
than 1.2.13. It does for example not have the serious serial bugs that
were not fixed until past 1.2.13.
I'd agree some things were a little misjudged but not much: ISDN you cited,
without it enabled it changes nothing. With it enabled it lets you use ISDN
that you couldnt have used before.
Putting out 2.0.x kernels as -pre before releasing them officially however
is definitely a smart move. I agree with the "theme" of some of your message
just not the examples.
Alan