J
Thomas B. O'Hanlan:
> > It seems that specifying a standard API for doing I/O would alleviate
> > some concerns. Maybe speed is the issue.
Curt Wuollet:
> That's what we are attempting to work out with this example. We have two
> votes for using the standard char driver API and Jiri thinks a userland
> driver would be just as easy.
I just don't see the point of going to the complication of a kernel driver when a userland process is sufficient...
Where a kernel driver is necessary (eg for interrupts) or already exists, sure, use it; but for the 8255 it seems like a lot of code for little effect. Surely a few inb()/outb() calls would suffice?
(And it's not just code - the installation complexity for a kernel driver is much higher, too, because it must be compiled alongside the kernel; all a user-land process needs is suid root. Quality must be better, because a kernel driver can stuff up much more than even an IO-privileged process. Fewer people are competent in compiling, inserting and configuring kernel
drivers than compiling and running programs.)
> We may do it both ways and see. One API for serial, direct attached,
> ethernet and fieldbus I/O would be great but I doubt it's practical
> unless you want to consider the interface to the mm an API.
The mm interface doesn't do any `configuration' type stuff (though the Great Namer was intended to do that, eventually).
In any case, we are going to need configuration stuff for other parts of the linuxPLC (logic engines, HMIs, PIDs, whatever), and all of those will be userland. An userland I/O process would seem to be just more of the same.
> There's more than one interface on some types as they need to be set up
> in ways that we don't want to do with the MM and there are other "out of
> band" functions. The char driver handles these with ioctl() calls. There
> won't be any for some types.
In any case, there will be a userland process which calls those ioctl()s. At that stage, it can simply take note of the stuff itself rather than
passing it on.
Again, please don't consider this `a vote against kernel drivers'. Consider it `a vote against gratuituous kernel drivers'.
Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> > It seems that specifying a standard API for doing I/O would alleviate
> > some concerns. Maybe speed is the issue.
Curt Wuollet:
> That's what we are attempting to work out with this example. We have two
> votes for using the standard char driver API and Jiri thinks a userland
> driver would be just as easy.
I just don't see the point of going to the complication of a kernel driver when a userland process is sufficient...
Where a kernel driver is necessary (eg for interrupts) or already exists, sure, use it; but for the 8255 it seems like a lot of code for little effect. Surely a few inb()/outb() calls would suffice?
(And it's not just code - the installation complexity for a kernel driver is much higher, too, because it must be compiled alongside the kernel; all a user-land process needs is suid root. Quality must be better, because a kernel driver can stuff up much more than even an IO-privileged process. Fewer people are competent in compiling, inserting and configuring kernel
drivers than compiling and running programs.)
> We may do it both ways and see. One API for serial, direct attached,
> ethernet and fieldbus I/O would be great but I doubt it's practical
> unless you want to consider the interface to the mm an API.
The mm interface doesn't do any `configuration' type stuff (though the Great Namer was intended to do that, eventually).
In any case, we are going to need configuration stuff for other parts of the linuxPLC (logic engines, HMIs, PIDs, whatever), and all of those will be userland. An userland I/O process would seem to be just more of the same.
> There's more than one interface on some types as they need to be set up
> in ways that we don't want to do with the MM and there are other "out of
> band" functions. The char driver handles these with ioctl() calls. There
> won't be any for some types.
In any case, there will be a userland process which calls those ioctl()s. At that stage, it can simply take note of the stuff itself rather than
passing it on.
Again, please don't consider this `a vote against kernel drivers'. Consider it `a vote against gratuituous kernel drivers'.
Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc