Two different things "supporting" and "allowing". Currently it is that BOM
are "allowed". (I am not entering the discussion on whether this is good
or bad.) Note that you will not find too many volunteer hackers jumping
in to help "support" users with BOMs - the lk archives will reflect this.
If a vendor decides to release a BOM, then it is implicit in their decision
that by doing so, they have voluntarily denied to accept the support that
comes from having many different persons auditing their code, if it was
available. Hence the issue of "support" lies on their shoulders entirely.
> (1) don't allow binary only modules at all
>
> (2) have a stable ABI for binary only modules and don't allow
> these binary only modules to use other symbols, so people
> in need of binary only modules won't be locked to one
> particular version of the kernel (or have two binary only
> modules locked to _different_ versions of the kernel)
One of the great things about linux is that code quality and performance
have always taken precedence over keeping an interface carved in stone.
We've tried to not make radical inteface changes in stable relases, but
where necessary it has been done, and we were free to do so. If a vendor
with a BOM can't take the time to appropriately update their code and
release a new BOM, then it is clear that they don't really support linux.
If someone has chosen hardware for which a BOM is the only option, then
they need to investigate in detail that vendor's support policy, and get
things in writing if need be (e.g. large installation base, etc) detailing
just how current bugs and new drivers for future kernels will be handled.
If a vendor wants $$$ for such a written support policy, then you have to
factor that into the overall cost of what you are setting up.
If someone is stuck with _two_ unsupported BOMs that are for two different
kernels, then I'd have to say they didn't do their homework when choosing
the hardware and/or determining if the level of support the vendor was
offering was adequate for their particular application. Caveat emptor.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/