Re: UDI environment now released.
On Wed, 14 Feb 2001, Robert Lipe wrote: Grard Roudier wrote: Being smart with kernel interface is important for drivers to be fast and reliable. Puting some stinky layer between native kernel interfaces and drivers looks horrible to me. Fast and reliable are both covered. For example, the specification (though not the current reference implementation) allows things like having different drivers and even different instances of the same driver in separate address spaces. Want to debug your driver in user space? It could happen. Reliability can be realized by making it impossible for a driver to panic the system. (And I do realize that flies directly in the face of fast. :-) Certainly not full impossible. DMA at some wrong place or not handling properly level-triggerred interrupt, for example ... A more recognizable reliabilty improvement is the more unified and constitent programming interface. No more "you can't call malloc with WAIT_OK while holding a spin lock on another processor at an elevated PL" bugs. This looks like matter of taste to me. Unless all O/S architects since day one until UDI have been incompetent idiots. :-) Why isn't UDI proposed as a native kernel interface, instead? In at least three OSes, it will be a native kernel interface in versions shipping this year. How the 'open-ness' of UDI is guaranteed? As a corollary: - Are these three mysterious O/Ses using some vendor-specific extensions or undocumented differences in their UDI stuff? - What the risk of UDI getting steered by some coalition of vendors? - Finally, as some large collection od UDI drivers may well exist, how can I download the source and how FreeBSD is intended to gain adavantage of this driver collection in the future ? The current "UDI Demarcation Point" isn't fixed. It can be moved to suit the needs of the host OS. As a practical matter, the thickness of that "layer" is very slim at runtime, so the potential gains aren't as large as some imagine they are. I want to beleive you here. In its early life, a very natural way to bring up the UDI interface (remember, we were developing spec, drivers, and environment simultaneously) was to do it in terms of existing kernel interfaces. UDI and the existing interfaces could be implemented side-by-side. In many cases, you could even make UDI the primary interface and implement another interface -perhaps the current interface for compatibility- in terms of UDI. I'm looking at doing exactly this in some of my OSes. Was the main point of my question. Thanks for the reply. Besides, if I walked into this crowd and said, "Here's a new driver interface and a megabyte of patches to /usr/src/sys. Whaddya think?", how quickly would you have thrown me out? That's what I thought. :-) A mega-byte large patch is not that unusual nowadays. :-) Now repeat that exercise for a dozen or so OSes... Only. :-) Grard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Grard Roudier wrote: A more recognizable reliabilty improvement is the more unified and constitent programming interface. No more "you can't call malloc with This looks like matter of taste to me. Unless all O/S architects since day one until UDI have been incompetent idiots. :-) Well, OK. If you don't mind, for example, having a different buffer model for network devices than you do for storage devices, it is a matter of taste. Why isn't UDI proposed as a native kernel interface, instead? In at least three OSes, it will be a native kernel interface in versions shipping this year. How the 'open-ness' of UDI is guaranteed? * The specification is open and freely available for download and use. (www.projectudi.org) * No royalties, membership fees, or initiation rites to contribute or use the spec. * Multiple implementations (including one with source under a BSD license) are available for interop testing. - Are these three mysterious O/Ses using some vendor-specific extensions or undocumented differences in their UDI stuff? I didn't mean to be mysterious: * SCO UnixWare 7 has a vendor (that's me) supported UDI environment available now as download.The next version will have it integrated into the base OS. * SCO OpenServer 5 will have a supported UDI environment in the first half of this year as a download. The next version will have it integrated. * AIX/5L has a supported UDI environment in the current prereleases. UDI will be available in the product at launch. If there are driver-visible differences, they are bugs and will be treated as such. And in some environments, we enforce things like accessing no symbols other than what's in the spec. Name your driver functions "lbolt", "kmem_alloc", "main" or anything else you like; you're not getting to the non-UDI symbols in the kernel of the same name. :-) - What the risk of UDI getting steered by some coalition of vendors? If you want to help steer, come aboard. We'd welcome it. Since we didn't start with some existing driver interface, it's not self-serving to assert any undue influence on things. There's enough architectural differences represented to keep things pretty neutral. You can see minutes of the (open) meetings and calls on the web site. - Finally, as some large collection od UDI drivers may well exist, how can I download the source and how FreeBSD is intended to gain adavantage of this driver collection in the future ? We're providing a few drivers on projectudi.sourceforge.net as samples. It will be, as always, up to the driver owners to decide how and where to distribute their drivers. If someone contributes a driver to the project, I'll gladly drop it in the tree. Now that the 1.01 specification is finalized and UDI is shipping as a final supported product one OS (UnixWare 7) with two more soon (OpenServer, AIX I expect IHVs many cases, you could even make UDI the primary interface and implement another interface -perhaps the current interface for compatibility- in terms of UDI. I'm looking at doing exactly this in some of my OSes. Was the main point of my question. Thanks for the reply. Good. Besides, if I walked into this crowd and said, "Here's a new driver interface and a megabyte of patches to /usr/src/sys. Whaddya think?", how quickly would you have thrown me out? That's what I thought. :-) A mega-byte large patch is not that unusual nowadays. :-) Perhaps not, but if I had carved up gensetdefs to allow builds outside the kernel source tree, changed the klm code to recognize .udiprops sections in an executable, and made newbus a little more forthcoming with information, don't you agree it would have been met with more skepticism? I just really didn't want to debug the host OS and the UDI environment at the same time. I didn't do it when I did UDI for the OSes in my day job, either. Maybe I'm a coward. Now repeat that exercise for a dozen or so OSes... Only. :-) Hey, I've gotta sleep once in a while. :-) Speaking of not sleeping, I had a major cvs commit party last night. I think I have all the FreeBSD code checked ito the udiref tree now. I fixed a binary incompatibility problem and have now successfully kldloaded UDI modules that were built on a UnixWare system. (The Linux/OpenServer/UnixWare interoperability has already been demonstrated.) RJL To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
On Wed, 14 Feb 2001, Matthew Jacob wrote: On Wed, 14 Feb 2001, Sergey Babkin wrote: Matthew Jacob wrote: The problem is that at the time this was a huge issue there were a much larger number of machines and pieces of h/w and radically different OS's (or flavors within Unix even) to support. Such a wide set of differences is not really there any more, hence the cost of such support (and the style in which it is being done) makes less sense than it used to. I'm afraid, it is. How many versions of FreeBSD with incompatible driver interfaces are out there ? Not too many. Major release rules have been adhered somewhat. Given an O/S, this looks like pragmatism to me rather than rules. Even when going to a new major O/S version, having to heavily rework the entire driver collection prior to a release would be kind of O/S suicide, in my humble opinion. :) How many versions of Linux with the same sort of incompatibilities ? Linux is far worse - the release of the moment Worse than what regarding what? 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. 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. :) 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. :-) Grard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Being smart with kernel interface is important for drivers to be fast and reliable. Puting some stinky layer between native kernel interfaces and drivers looks horrible to me. Why isn't UDI proposed as a native kernel interface, instead? Note that last time I read the specs, I haven't been this impressed.:) Grard. On Wed, 14 Feb 2001, Robert Lipe wrote: I'd mentioned a few times on this list that I had tinkered with a port of UDI, the Uniform Driver Interface, to a FreeBSD environment while waiting for our lawyers to get their acts together[1]. Well, I got the final clearance and the code was released today at: http://projectudi.sourceforge.net The FreeBSD environment isn't included in the release yet, but from here it's merely an editor exercise to release that pile of bits. The common code is all there and I think there are only two or three mods to common code required for the FreeBSD port. I hope to get it checked into the udiref tree this week. I'm not a FreeBSD jock, so I focused on getting the "UDI parts" under control more than taking advantage of FreeBSD services. It works well enough now that the remaining pieces could probably be developed independently. For example, a SCSI mapper could probably be stamped out by someone that knows the FreeBSD storage system and is comfortable reading the Linux, UnixWare, or OpenServer SCSI mappers and understanding only a very small amount of UDI. Similarly, someone that understands the FreeBSD DMA system could grow the DMA implementation in relative isolation. I have it hobbling along well enough that a network driver running in isolation (not talking to the network stack) will bind, deliver/service interrupts, and do DMA long enough to deplete VM becuase of the leak in contigmalloc. (Yes, yes, I know this is still evil...) There are a couple of Really Horrible things I did to get the FreeBSD stuff up rapidly, but I'd like to work with interested parties to get it going well. I'm a little torn between just checking in what I have now (including horrible 4.1.1 newbus bus enumeration hack and special cases for a specific PCI ID that I was testing) en-masse or dribbling it in as I clean it up. I'm leaning toward the former, but a strong partner could change my position to the latter. RJL [1] Try getting a dozen lawyers from some of the largest computer companies you can name to agree on anything... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Being smart with kernel interface is important for drivers to be fast and reliable. Puting some stinky layer between native kernel interfaces and drivers looks horrible to me. Why isn't UDI proposed as a native kernel interface, instead? Note that last time I read the specs, I haven't been this impressed.:) In my opinion, UDI is trying to solve what was a very important problem about 10 years ago (a kernel ABI for single h/w classes and a common kernel API to provide more portable driver support). Various efforts (the ATT and Solaris DDI/DKI and even the IEEE OBIOS efford come to mind) came about to try to tackle this. The problem is that at the time this was a huge issue there were a much larger number of machines and pieces of h/w and radically different OS's (or flavors within Unix even) to support. Such a wide set of differences is not really there any more, hence the cost of such support (and the style in which it is being done) makes less sense than it used to. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Grard Roudier wrote: Being smart with kernel interface is important for drivers to be fast and reliable. Puting some stinky layer between native kernel interfaces and drivers looks horrible to me. Fast and reliable are both covered. For example, the specification (though not the current reference implementation) allows things like having different drivers and even different instances of the same driver in separate address spaces. Want to debug your driver in user space? It could happen. Reliability can be realized by making it impossible for a driver to panic the system. (And I do realize that flies directly in the face of fast. :-) A more recognizable reliabilty improvement is the more unified and constitent programming interface. No more "you can't call malloc with WAIT_OK while holding a spin lock on another processor at an elevated PL" bugs. Why isn't UDI proposed as a native kernel interface, instead? In at least three OSes, it will be a native kernel interface in versions shipping this year. The current "UDI Demarcation Point" isn't fixed. It can be moved to suit the needs of the host OS. As a practical matter, the thickness of that "layer" is very slim at runtime, so the potential gains aren't as large as some imagine they are. In its early life, a very natural way to bring up the UDI interface (remember, we were developing spec, drivers, and environment simultaneously) was to do it in terms of existing kernel interfaces. UDI and the existing interfaces could be implemented side-by-side. In many cases, you could even make UDI the primary interface and implement another interface -perhaps the current interface for compatibility- in terms of UDI. I'm looking at doing exactly this in some of my OSes. Besides, if I walked into this crowd and said, "Here's a new driver interface and a megabyte of patches to /usr/src/sys. Whaddya think?", how quickly would you have thrown me out? That's what I thought. :-) Now repeat that exercise for a dozen or so OSes... RJL To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Matthew Jacob wrote: The problem is that at the time this was a huge issue there were a much larger number of machines and pieces of h/w and radically different OS's (or flavors within Unix even) to support. Such a wide set of differences is not really there any more, hence the cost of such support (and the style in which it is being done) makes less sense than it used to. I'm afraid, it is. How many versions of FreeBSD with incompatible driver interfaces are out there ? How many versions of Linux with the same sort of incompatibilities ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
On Wed, 14 Feb 2001, Sergey Babkin wrote: Matthew Jacob wrote: The problem is that at the time this was a huge issue there were a much larger number of machines and pieces of h/w and radically different OS's (or flavors within Unix even) to support. Such a wide set of differences is not really there any more, hence the cost of such support (and the style in which it is being done) makes less sense than it used to. I'm afraid, it is. How many versions of FreeBSD with incompatible driver interfaces are out there ? Not too many. Major release rules have been adhered somewhat. How many versions of Linux with the same sort of incompatibilities ? Linux is far worse - the release of the moment 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. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
The differences are still there, and it's usually soo tough to get companies to provide drivers for FreeBSD. Yeah IBM GPL'd some winmodems, no one has mentioned a FreeBSD port... Although the issue might be political, UDI might be the way to finally get over the "designed only for windows ..and sometimes other OSs" type of hardware. Special kudos to Robert Lipe for recognizing the value the FreeBSD community can have in the adoption of new, truly open, standards! Pedro. Matthew Jacob wrote: ... The problem is that at the time this was a huge issue there were a much larger number of machines and pieces of h/w and radically different OS's (or flavors within Unix even) to support. Such a wide set of differences is not really there any more, hence the cost of such support (and the style in which it is being done) makes less sense than it used to. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message begin:vcard n:Giffuni;Pedro tel;fax:1 (360) 343-0501 tel;home:(412) 665 2956 tel;work:(412) 624-9862 x-mozilla-html:FALSE url:http://www.geocities.com/giffunip/ org:University of Pittsburgh;Industrial Engineering adr:;;5820 Elwood St. Apt. 34;Pittsburgh;PA;15232;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Teaching Assistant fn:Pedro F. Giffuni end:vcard
Re: UDI environment now released.
The differences are still there, and it's usually soo tough to get companies to provide drivers for FreeBSD. Yeah IBM GPL'd some winmodems, no one has mentioned a FreeBSD port... Although the issue might be political, UDI might be the way to finally get over the "designed only for windows ..and sometimes other OSs" type of hardware. Special kudos to Robert Lipe for recognizing the value the FreeBSD community can have in the adoption of new, truly open, standards! I'll repeat what I've said before: "Over my dead body". -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Matthew Jacob wrote: The differences are still there, and it's usually soo tough to get companies to provide drivers for FreeBSD. Yeah IBM GPL'd some winmodems, no one has mentioned a FreeBSD port... Although the issue might be political, UDI might be the way to finally get over the "designed only for windows ..and sometimes other OSs" type of hardware. Special kudos to Robert Lipe for recognizing the value the FreeBSD community can have in the adoption of new, truly open, standards! I'll repeat what I've said before: "Over my dead body". As a native interface no, but I think that as an auxhiliary interface to allow us to run third party drivers it's a very valuable service.. Thanks you Robert! Robert, Don't let the negaive comments get you down. The UDI driver service is valued,at least by me and I'm sure by many others too! Consider the negative comments to be just that... 'comments' and I'm sure that even the authors of most of these comments will say that over-all they are happier that you did this than not at all. (Even if they have doubts about UDI) -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Let me clarify that I don't really mean to be negative about these efforts- I just don't want them to distract us from other issues of great importance for FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
