Eric Lowe writes:
> A really rough strawman might look something like the following community 
> structure in place of "core OS":
> 
>    kernel
>    user commands
>    libraries
> 
> but that's not perfect either.

No, it's not.

I suppose the problem is that we've really got overlapping sets here,
and that no tidy breakdown is going to work.  NFS is networking and
it's a file system.  Devfs is I/O and a "core OS" component.  VM is
(at least) file system and core OS.  (And I'll refrain from ascribing
memberships to STREAMS.  ;-})

So, either we have to just come up with an essentially arbitrary set
of groupings, and assign components to each one until the last scrawny
kid gets chosen for a team, or we create lots of groupings that
intentionally overlap but likely reflect much narrower interest areas.

One way to deal with this sort of uncertainty is the usenet model.
You create a minimal set of top level groups, and you create more
focussed areas *only* when there's been an excruciating amount of
traffic on one particular topic by a subset of people -- enough so
that it's clear that nobody else on the general list cares, and enough
so that we know the discussion isn't going to go away any time soon.
In other words, create a new grouping only when pushed hard, and not
when we just notice a likely-looking interest area.

> > (For what it's worth, I'm not happy with the existing networking
> > group.  Why wouldn't X.25, SNA, ATM, and other basic networking
> > technologies be part of that group?  Why is it just a subset of
> > TCP/IP?  But, then, if I were happy ... ;-})
> 
> If the existence of a networking community isn't the right thing, do you 
> believe that networking could be merged into kernel and user commands 
> communities?

There are certainly parts that are kernel and parts that are user
commands.  And there are parts that are clearly administrative in
nature.  There are also parts (such as the daemons) that are just
"other."

> Taking Linux-kernel as an example (though you can argue their model is too 
> broad) filesystems, networking code, and even drivers are part of one 
> community.

That doesn't seem like an obviously bad idea to me.  I see a lot of
affinity among those things.

> What about file systems? Why have ZFS and UFS communities (and possibly 
> NFS in the future) instead of one file system community with three file 
> system projects under it?

Indeed.

> What about drivers? There's no home for them yet, and I (in my little 
> corner of the world) expect drivers to be one of the biggest areas for 
> contributing code as it is in other open source OSes.

Right.  And the issues that driver writers deal with are *often*
kernel issues, such as where to put common bits of functionality (we
don't really want to have 27 separate MII implementations), how to
deal with special functions like zero-copy (just how long can a page
be pinned down?), and general locking and consistency problems.

> It sounds like there is a grumbling that the bigger picture of community 
> structure needs to be re-thought, and that isn't what we signed up for 
> with our proposal :), but on the other hand I certainly can see the need 
> to rethink the whole structure. OpenSolaris has grown a lot lately, and 
> the time might be right for a revolution.

Just like the swamp that kernel/other represents, I suspect that
there's an irreducible set of just plain old miscellany (maybe modhash
goes there).  But for the same reason that kernel/other is a bit of a
dumping ground, it'd be good to tailor any sort of catch-all group
(which is how I see "core OS") so that it's a last resort rather than
path of least resistance.

I don't know if that represents revolution, but maybe just that "core
OS" should be clearer on component membership.

-- 
James Carlson, KISS Network                    <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to