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.