From: Gábor Lénárt (lgb_at_lgb.hu)
Date: 2007-09-26 13:57:01
Hi, On Sat, Sep 22, 2007 at 01:52:56PM +0200, Spiro Trikaliotis wrote: > In Windows, you are using "deep in-kernel stuff", too. The only > difference: MS is documenting what you are supposed to be using. Thus, > as long as you stay with these, the driver is likely to be able to run > with newer versiosn of the kernel, too. For being short (because it's declared Off-topic here), the problem: Windows has got some abstraction layer which is designed to be quite constant in time (well at least in short time range I guess ...), so there is some driver API. Introducing an extra layer/API solves the problem, and hides the deeper changes inside the kernel itself. Also Windows has got quite different development process, a windows version would stay for ages in some cases which is not true for Linux (ok, it has got positive AND negative impacts as well). Sure loading a "driver" or "module" is a some kind of "real time linking" both on Linux and windows, but in case of Linux, that's really a part of the kernel (not through a "standarized" driver interface or such at all), eg you can compile most feature as module as built-in too, this clearly show that it's VERY different from the similar notion of Windows, when there is no such an ability, but a strict abstraction layer for this purpose. I mean: in case of Linux the whole goal of "modules" was not designed as 3rd party driver interface (it's another question that nowdays it's being used for that purpose by some vendors with more or less success) but for the ability not to compile in all the drivers into the kernel (statically) for a distribution. > I am sorry, but this is ... - No, I do not want to start a flamewar. > Nevertheless, what you are essentially saying is: "It's not a fault, > it's a feature." Somewhere, deep in my memory, I have heard this > argument before. > > In my view, it is more like "broken by design". Unfortunately, it is It depends on your mood. For example I can treat closed source as "broken by design", and in this case, I don't want anything linking against az open source stuff through an abstraction layer which makes easier to "infect" an open source project with closed source blobs (even now Linux kernel developers refuses debug problems if kernel is 'tainted' since there is no way to debug the effect of a closed source module to the system. however even Microsoft often blames 3rd drivers for Windows stability problems, they use some validation process now to call a driver 'stable' - sorry I don't know the exact name for this notion -, unfortunately it's cannot be done with Linux easily because vendors of closed source drivers won't give source to Linux developers without an NDA or such, because it would almost certainly result in blames that open source developers steeling NDA protected infos in their further developments - they release source remember? - , and of course it's not open source spirit either. So nowdays kernel developers are in strange situation that they cannot debug problems of their users because of closed source blobs injected in their system whose effect to the whole kernel is highly unknown for them). So you're right from some kind of viewpoint, but in this case, open source is broken by design as well. At the other hand, I see the opposite of this, that closed source is broken by design. But this flame can be gone on without end, so it's not worth. Sure, if we're speaking about OpenCBM it's a problem because it's not a closed source stuff, that's why I've writtin that it's quite off-topic here. I don't want to open flamewar about this fact, because you're right here: for OpenCBM it's a problem! Just wanted to show that this problem is not caused because ugly and evil Linux kernel developers don't want 3rd modules _at_ _all_, but because of other facts too (and mainly). > The only difference I see: While MS *encourages* you to make your own > drivers for our own hardware, the Linux guys mainly *discourage* you > unless you are doing it exactly like THEY want you to do it. Thus, in > order to support Linux, you have to follow their rules (or shut up.) As with windows. Eg you must sign NDA to see some source/spec, etc. But with Linux or other open source project you have the right at least to access source freely, then of course it's up to you to use that or ignore it, so you have the freedom of choice. That's freedom: you can get the facts (even read the last chars in the source) and then you have right to choose or not choose it. Also, you can read file "stable_api_nonsense.txt" from the kernel source tarball (from directory Documentation). That's was my fault to interpret the first letter in this thread about a missunderstanding of Linux or something similar, I admit it, so I think it doesn't worth to continue this flamewar IN GENERAL, about OpenCBM, it would be quite different topic, sure. For OpenCBM it's really a hard question, it's true. Because it's a quite special driver which is needed for only a few people (well, compared to the number of all Linux users, I mean), and it's harder to be the part of Linus' source tree for a driver which is so special. > > Sorry, I don't know OpenCBM well, but it would be also interesting idea to > > think about OpenCBM implementation, like device drivers in user space > > (http://lwn.net/Articles/66829/). > > Tell me how you want to achieve a timing precision of 4 us in > user-space, and we will speak of this again. Don't know, that's why I used conditional mode in my sentence :) Sure an external uC would solve the problem but than it would be an extra hardware as a requirement so it's not the best solution for all. > > It's the same idea as FUSE (filesystem in > > user space). Sure, because of direct hw access, some kernel part may be > > needed. This is about the idea that not everything should be placed in > > kernel space, some things would fit better into userspace (just think about > > special filesystems like sshfs and gmailfs: without FUSE they would be > > almost impossible to do in kernel space). > > This is true; in fact, it is EXACTLY the approach OpenCBM uses: Only the > parts absolutely necessary are in the kernel space. > > Note that another option would be to use some RT extensions for Linux. > Nevertheless, the "RT extensions" all people are speaking off nowadays > are far from being able to achieve that precision needed for OpenCBM. It Yes, RT is not something that many people think: it does not mean that you will have got ultra-hyper-very low answer from the OS, it simply means that you have _some_ (should be specified) but _guaranteed_ response time. Maybe it's worth to use extra external hardware after all? If it's cheap enough (and eg using USB as hw interface towards the PC, it would be comfortable: modern PCs start loosing 'legacy' ports, it seems) it would be suitable, eg it would handle most of the timing problems, and maybe it's easier to implement a driver for the OS itself, as well because of the external hw "help" from the uC. Maybe, even a "driver in user space" would be enough? -- - Gábor Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.