James Carlson wrote:
Andrew Gallatin wrote:
James Carlson wrote:
But the proposal under consideration doesn't actually address those
problems. It provides you yet another place to put your sources, but
one in which the sources will _still_ not be kept up-to-date with
respect to private interface changes, such as those in GLDv3. It's
still a backwater, and does not have the helpful burdens of ON: when
changes happen, nobody's going to update your source to conform.
No, the proposal was for build-for-build compat with ON.
The folks doing the Nemo changes will not visit this new consolidation
and update your driver for you.
If your driver is part of ON, they'll be _forced_ to update any drivers
that are affected. If it's not, then they're not compelled in any way.
So who does that work of keeping all the drivers up to date with the
latest Nemo changes?
If it's the consolidation maintainers, then bully for them. They're
making a huge commitment.
If it's the driver authors, then I don't see how it's different from
shipping your driver source on your own web site. Except, perhaps, that
it's a little less convenient.
I would say that it is the driver authors. You setup a tinderbox,
and email driver authors when their driver fails to build. If
their driver fails to build for some number of releases, it gets
removed.
I'd argue that it is much more convenient than a single UHV trying
to track ON itself. I have no idea when new versions of ON
come out. I've never built ON from source, etc. I spend about
10% of my time on Solaris, and I couldn't justify the time to
setup an automatic build system myself. But if this project
provided it, that would be awesome.
That they provide less functionality and performance than some users
might like is certainly a defect, and the fact that the long-proposed
replacement isn't yet stable enough to be public is a real shame, but
it's certainly _not_ the case that this means Solaris has the same Linux
drawbacks. It only seems that way if your code is dependent on GLDv3
and (for whatever reason, including performance) you're unwilling to
work with the alternatives.
GLDv2 doesn't even offer LSO. It is laughable. Especially
since v2 could be easily extended to support LSO. GLDv2
is just not a realistic option to expect anybody to use
these days.
I'm sure your driver needs LSO, as do some others. That doesn't mean
every driver does.
I think my point was missed.
Hell, you can't even ship *SOURCE* and expect a user to build it
because the non-stable interface header files are not published
outside the HG tree. At least on Linux, you can ship source
and have a reasonable expectation that a user can compile your
driver.
Even if the headers were shipped, they'd do you no good. You'd still
end up with binaries that sometimes roach the system, or, if you're
lucky, sources that fail to compile at all across software updates.
Not if you put a bit of common sense into it, and installed modules
using private interfaces into a private, kernel-version specific
place. Its not hard. Linux does it (/lib/modules/2.6.31/...).
FreeBSD does it (/boot/kernel/... with 3rd party drivers using stable
interfaces in /boot/modules). Linux even has a mechanism (dkms)
to re-build 3rd party modules automatically at boot time when
the kernel is updated.
That just moves the problem to another module. Who maintains that?
You complained about stale drivers "roaching" the system. I provided
a way to avoid that. What is to maintain? If you mean the drivers,
see above.
If it's not the people making changes to the Nemo bits, then we're back
where we started.
If it is, then putting that module into ON and having it maintained
properly would be the best answer. Maybe it's "the" answer for Nemo.
(Though it does beg some questions.)
That's the bad thing about private interfaces, particularly when used in
areas where public interfaces are really required.
Fixing that defect seems like a very important goal -- far more
important than much else that's likely being done now -- but I don't see
this proposal helping in any notable way.
If it provided a place where build-for-build binaries were generated,
it would help immensely.
You can do that today with wget+make. It doesn't have the other
important attributes of a consolidation -- namely, the oversight.
I'd argue that setting up an IPS repo, and automating builds
corresponding to ON releases is a little more complex that
"wget + make"
Drew
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
