Date: Thu, 15 Feb 2001 08:45:52 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: Sergey Babkin <babkin@bellatlantic.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: UDI environment now released. Message-ID: <Pine.BSF.4.21.0102150822470.17531-100000@beppo.feral.com> In-Reply-To: <Pine.LNX.4.10.10102150859510.605-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Worse than what regarding what? Stability of interfaces. > > A far as the topic is kernel interface changes between major versions > (that seem to affect the second digit in Linux versionning), I donnot see > your point. Au contraire, most (all?) Linux kernel interface changes I > have had to take into account in some drivers seemed to have been designed > in order to minimize driver code changes. Just take a look at any SCSI HBA driver- and I learned how to cope with Linux from you :-) on this! - it isn't a change like: #if VERSION < 2 #elif VERSION < 3 #elif VERSION < 4 ... it's more like #if VERSION < 2.23 #elif VERSION < 2.44 #elif VERSION < 3.11 #elif VERSION < 3.23 #elif VERSION < 3.55 #elif VERSION < 3.99 #elif VERSION < 4.21 ... Now- granted that the 'odd' numbered releases are development and you'd except a lot of changes but many of the changes that occur could have been forseen upfront, and things staged more evenly- I'm thinking of the evolution of the PCI interfaces for example. > About the Linux release of the moment.... :) > > But we must consider the hudge amount of changes between Linux-2.2 and > Linux-2.4. I am under the impression that the differences between > FreeBSD-4 and FreeBSD-5 kernels will be of a comparable order of > magnitude. How better FreeBSD will cope whith such mega release is what we > must focus about instead of doing not yet relevant comparisons, IMO. :) Sure. But you won't hear me saying that the way we've done -current is, umm, the most desirable way to do things. It could have been a lot worse though. > > > But the primary motivation for a UDI like i/f (which, btw, has a lot *not* > > going for it) in terms of multiplatform support is not the issue it once was. > > Ah? My English-to-French parser oopsed here. You may reword it. :-) My Brain-to-Fingers parser oopsed and that was the result. Actually, the above is an example of what it's like to program in Forth (or to speak in German). Let's try again: The issue which seems to have been a primary motivation for UDI is not, in my opinion, as serious an issue as it once was. The issue has to do with providing a common set of kernel services (APIs) against a a very broad set of platforms so that very expensive but essentially identical driver work doesn't have to be done over and over again. This issue is not as serious because the number of serious platform contenders has shrunk by an close to an order of magnitude. Now OS platforms like NetBSD and Linux have gone to a considerable to try and cover a broad range of platforms (with different strategies- NetBSD invests a considerable amount of effort in Machine Dependent/Independent split models; Linux seems to have solved this somewhat quicker by punting a lot of things (like ioctls) into machine dependent code)- most of which are 'legacy' platforms. I don't wish to offend anyone- but "legacy" means "legacy"... If the commercially viable set of hardware platforms has shrunk to ia32/ia64 followed by rapidly shrinking percentages for sparc64, alpha, PowerPC and 'other', and if the common unifying I/O bus for all of these platforms is PCI, what's the point of a unifying driver software model like UDI? Urr.... *blush* ...I just think I argued myself into a corner. Now what *did* I mean.....??? Oh- yeah- if there's only 3-4 platforms, and all have the same I/O bus (more or less), then the amount of difference to drive the actual hardware itself is trivial- and one doesn't need a grand scheme like UDI. There are other rasons to have something like a UDI- which are more software midlayer types of issues- Networking, SCSI, etc. I wont speak to Networking, but in terms of a SCSI midlayer *none* of the systems we have are adequate (although CAM comes closest) to cope with the available hardware and what customers actually need. But if one is to have a unifying set of services like UDI, it should be looking forward, not backwards, and the issues it deals with and the services it provides (which can, like the base h/w platform issue I spoke of above, support the now maybe 2 serious SCSI HBA vendors) don't come close to looking at the serious issues now are. (Oh dear, I should just shut up......) -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0102150822470.17531-100000>