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
