Jim,
I think you're totally ignoring the real problem that exists. I'll
respond inline, but you've not offered any solutions to the problem,
only finding fault with this approach.
James Carlson wrote:
Garrett D'Amore wrote:
James Carlson wrote:
Does that imply that Sun never pulls bits from this consolidation? Even
if they're good bits that people want?
Whether Sun pulls or not is up to Sun. The point is that Sun's business
needs don't get to determine the rules for integration into this
consolidation.
It sounds like that's the problem that ought to be fixed.
Good luck. Sun has kept the reins very tight on OpenSolaris (the
distro) and on ON. Nothing goes in that Sun doesn't want to go in. And
stuff comes out even when other people don't want it to come out. The
recent EOF's of all SPARC workstations are a good example -- nobody
consulted the community -- it was just fiat accompli.
You can't fix this. And I suspect the reins are not going to get any
looser when Oracle takes over.
Pretending you can "fix" this problem is living in fantasy land.
In other words, I think we're mostly agreed that the process ON has
(excluding any management-meddling part) is mostly good, and keeps the
dragons at bay. So why is this new consolidation different in that
respect as well?
There are times when one needs or wants to go into the dragon's lair.
The ON process is great for keeping the quality of Sun's products, and
the core distribution, high. However, there are folks who'd happily
sacrifice some of those quality guarantees just to be able to *use* the
darn thing on their hardware.
I believe that's no accident.
Its not, but its also designed historically around concerns for a
commercial product. There are real cases where commercial interests and
interests of the community diverge. The community written "cge"
replacement for "ce" is an excellent example. As is the revival of
UltraSPARC-1 support.
Why are drivers in particular special in this regard? What about people
wanting to deliver base OS applications that ON doesn't want? Can they
also integrate code into this alternate ON? (E.g., consider replacing
ksh93 with "some-person's-name-sh".)
I'd like to keep this focused on drivers. Drivers (and platform
support) are special because they might be needed at early boot, and a
common consolidation is the best way to deliver this for use by other
distros.
Non-drivers can integrate via /contrib now.
Does it include pseudo-drivers, or only real bona-fide "hardware" drivers?
The intention here is *hardware*. We're not trying to make an
alternative OS; at least that's not my intention. (I suppose
pseudo-drivers that work with other real hardware drivers might be
acceptable, but this is probably an edge case and splitting hairs.)
So, when my driver requires ON-wide changes (no matter how small), am I
forced into ON? Or do I fork yet another mini-consolidation?
I think at that point you're talking about something that should be in
ON. If it isn't in ON, then you're really talking about a fork of the
operating system proper. That's _not_ what we're trying to do.
I don't expect Sun to go into this consolidation looking for stuff to
integrate.
Really?
I expect this thing to be a dumping ground for one-off and mostly
half-baked but still quite necessary x86 drivers. And when the next
f*(&^%*(&^ SAS chipset comes down the pike, the only usable driver will
be available here -- and not in ON and not in OpenSolaris.
In fact, if I were a Sun employee, I'd strongly consider delivering here
rather than in ON. Process is a drag.
If that happens, it will happen only with the help of complicit
managers. Because I *don't* expect any Sun distro to use any of these
bits. It could happen, but at that point I'd seriously question whether
integration into ON for those bits isn't better. (And I'm saying I'd
question it as a Sun employee and ARC member -- if its going to get
official support as part of a Sun product, then it should adhere to the
same rules that we have for other Sun software.)
I do think some drivers might come here *first* before
they're ready to make the commitments that ON requires, and eventually
later integrate into ON. Yeah, its more work. But the payoff here is
potentially an early access to the bits for end users.
Early access is a problem that can be solved in ways other than creating
a consolidation, I think.
Perhaps.
Just creating a project for the new driver and having a convenient way
to publish fresh bits to /contrib would solve that problem. Heck,
that'd solve many problems besides just drivers, and it's something the
IPS folks want to see solved!
That only helps for software that isn't required during early boot. Low
level platmod stuff, and boot drivers fail.
I agree that this leaves open the possibility that others may deliver in
ways that don't get included in that distribution, but isn't it
_obvious_ that integrating into the OpenSolaris distribution
(particularly by way of ON) is a *guarantee* that the project in
question is widely-available?
It is. But you keep making this assumption that its easy to get into ON.
I don't believe I have made that assumption. Mostly because I believe
the opposite: it's hard to get into ON. And that's not all a bad thing.
Its not. I'm not proposing torpedoing ON's process. I'm proposing that
there are some things that should be exempt though... the exemptions
should only be for software bits that are *not* part of a Sun distro
(though that decision is for Sun's mgmt and C-Teams), and intended only
as a loose "caveat emptor" kind of thing.
Note that alot of the ON process has *nothing* to do with *quality*, and
everything to do with Sun's business. (Do you have i18n resources lined
up? Do you have a manager who's agreed to provide long term sustaining
support? Have you done a TOI? Have you made hardware available to the
sustaining group? Have you had a legal review of your code done?) And
then it gets worse -- there are times when Sun knowingly accepts
*inferior* solutions because a sustaining manager won't sign up or other
internal politics. (The fact that we will *never* have a Sun supplied
GLDv3 cassini driver -- *despite* the fact that I had one nearly done
that I would have contributed to Sun at *no cost* is an excellent
example -- it was pure politics. The fact that an excellent community
supplied driver for certain LSI hardware could not get integrated
because of politics involving Sun and LSI and support agreements is
another excellent example!)
That leaves end-users (and distribution builders!) an option to pick and
choose stuff that might not fit within Sun's business goals.
That's the point I'm making. If the driver is good, and everybody wants
it, then having it in the base OS rather than camping out in an
architecturally questionable (private interface stretching) home
directory consolidation would be a benefit for all -- including other
distributions.
"Everybody" is subjective. Case in point : UltraSPARC 1. Lots of
people want it. Lots more people think its pointless at this late date,
and Sun doesn't want it in ON because they don't want to support it
anymore (for good reason, actually!)
Who's right?
And when VM and dtrace and ZFS and others in ON make optimizations that
are either inapplicable or just downright incompatible with UltraSPARC
1, what exactly will you do?
It hasn't happened yet. If it occurs, then the CTeam for CSHW will have
to decide what to do next. I know you're trying to poke holes in the
idea, but the reality
That was a very big part of the reason for shutting down UltraSPARC 1:
to make things easier on those other project teams, so that they don't
have to lug around the burden of long-dead hardware.
Bzzt! No, the reason was that certain UltraSPARC-1 cpus have a security
bug when running 64-bit mode, and we wanted to ditch support for 32-bit
mode SPARC (because that *was* a major headache.) I *agree* with this
decision.
But there are people who have UltraSPARC-1 systems that don't run
untrusted code on them (and have no untrusted users on them) who still
want to use them. (Frankly I find this particular idea a bit nutso, but
that doesn't change the fact that these people are *out there*.)
The question is -- should Sun have the right to forever prevent them
from being able to reintroduce support for their systems? Certainly Sun
shouldn't have to *ship* support, but if they want to hack something up,
shouldn't other distros be allowed to make different decisions?
And that brings me right back to my original point: you're not
considering system architecture here, and what you're proposing may not
be doable over the long term, except for trivial things such as
monolithic and GLDv2-based Ethernet drivers. That's not a
"consolidation," as it lacks coherent management.
I think you're mistaken. I've actually done a project like this in the
past -- at Tadpole. Its hard, and it has challenges. Its not ideal.
But it *can* work... it *has* worked. (We had our own "consolidation"
that worked very much like what I'm proposing here... we used it to
supply Cardbus on SPARC systems and WIFI *years* before Sun had anything
comparable.)
My point is that by making this available, we don't have to force the
question. Let the users, and the distribution builders choose what they
want.
I wish we had a better way to let them choose what they want out of the
existing consolidations. Then we wouldn't see driver writers
threatening to take their ball and go home.
You need more than that. You need to loosen the reins on ON itself. As
I said, good luck with that.
I guess I should clarify here -- I don't expect anything in this
distribution to "mainstream". It might be stuff that once was
mainstream, but at the time of integration into CSHW, it will almost
certainly represent bits that are believed (by Sun at least) not to be
mainstream (or bits for hardware that might be mainstream, but for which
the driver is simply not yet mainstream ready).
That sounds like "unintegrated project," and not "consolidation" to me.
That sounds like "wordsmithing" to me.
My question is how project teams should choose between the two universes
and whether this new consolidation would ever reject a proposed
contribution.
I suppose rejections will happen far less frequently than ON does. Its
a simple question, really:
1) If you want to be on the "standard" installs, and pretty much
deployed everywhere, try for ON.
2) If your bits are much more limited in interest, or you can't get
agreement to get them into ON, then CSHW is your route forward.
So, if I don't care about (1), but the distributors do, then I'm still
free to avoid ON and take the cheap way out, right?
You are, but then the distributors better understand that taking from
CSHW also means that a greatly reduced level of support is present --
this is all caveat emptor.
Suppose I decided to rewrite Nemo and proposed that I toss the results
into this new consolidation. Would you accept or reject such a plan
because of its overlaps with ON?
You've already said you'd accept competing or "alternative" drivers, so
where is the line?
I think you're trying to make the problem worse than it should be.
I don't think so. I think it's worse than you imagine. ;-}
As I already said, I've been down this road -- for real -- before. Its
not that bad.
As Nemo represents a common "framework", and such changes really do
belong in ON, I think my first reaction would be to reject this
particular instance. It mostly violates the "duplicated functionality"
that I already described in my original proposal.
So what's the justification of an "alternate" driver? Is that not a fork?
I imagine the justification for something like "cge" would be --
a) superior features/support/performance
b) open source, and
c) no chance in hell that ON will ever accept a 3rd party
contribution for it
You'd have a much harder time convincing me that these are true for a
major rewrite of Nemo than Jason and Steve will have convincing me of
that for their "cge" replacement for "ce".
What's really critical here is that 3rd item.
That it is not to say that we would never reject such a proposal -- if
the sponsor could justify why this was necessary and useful, and why
delivery through ON was not practical, the CCs might agree to it. But
it would require fairly extenuating circumstances, and right now I can't
think of any reason we'd do this.
If I don't like ON's rules and I'm writing a framework component, then
it sounds like I need to create a third alternative for me and my
buddies. :-/
Yeah, probably. At that point, maybe you're really looking at a whole
fork of the OS. Its already been done, btw -- AuroraUX.
* if significant community members decide that they want continued
support for some piece of hardware -- lets say cg6 for example -- how do
you believe they should proceed?
a) try to get into ON -- fail because Sun won't do it
b) try another consolidation? Which one? (This is why I'm proposing
CSHW).
c) give up. that's the only option available *today*
Create a project for your driver. Projects need not ever integrate. If
they do, that's great. But they don't have to. Unintegrated projects
can (and should) be allowed to deliver bits into distributions. In
fact, they do this *today* -- IPS delivers via OpenSolaris.
That model sounds to me nearly ideal for drivers.
This fails in numerous respects for things that need to go beyond normal
driver interfaces... such as platmod support. You might need to be
present during early boot for example.
There is also value in having *one* consolidation for this, with *some*
controls (code review standards, known to compile properly, and
gatekeepers watching ON flag days for potential gotchas), then a
universe of a dozen (or dozens!) of different drivers in random places
on the network.
We have lots of unintegrated driver projects already today. Its highly
suboptimal.
Again, I'm trying to *solve* problems here, not create them. If I can't
solve them in the context of the OpenSolaris community, then I'll do it
elsewhere.
All I see are problems moving around, and extra work being added to
manage a very loose (and not consolidated) set of sources. It's a CINO;
a consolidation in name only.
Whatever. I am through trying to convince you, because its clear to me
that you don't really understand the real problems that exist -- or live
in a fantasy land where they are all trivially solvable with a wave of
your magic wand.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
