2.5.17 /dev/ports

I often use it as an alternative to #include <asm/io.h>, which you decreed illegal. I understand <sys/io.h> is a legal alternative, but a bunch of platforms forget to
include <sys/io.h>, for instance Jes cried bloody murder when asked to add it to ia-64. But if you decide to drop /dev/port I can tough it out. Solaris lives without it, and so can we.

I saw this whining about outl not implemented for write(fd, &my_int, 4), and I think the guy had a little point. Though if he wanted it, he ought to submit a patch.

-- Pete

Hey and finally if someone want's to use /dev/port for developement on some slow control experimental hardware for example. Why doesn't he just delete the - signs at the front lines of the patch deleting it plus module register/unregister trivia and compile it as a *separate* character device module ? That's linux - you have the source, so use it.
You wan't to cheat around the OS abstractions - do it for yourself! There is no requirement that it has to be
permanently in the mainline kernel where it tends to attract people who shouldn't have used it in first place for generic stuff like kbd rate settings and clock device manipulation.

That's not a productive approach, Martin.

Yes, with open source you can do whatever you want.

HOWEVER, there is a huge amount of advantage to having a common base that is big enough to matter: why do you think MS does well commercially?

It's important to _not_ have to force people to do site-specific (or problem-specific) hacks, even if they could do so. Because having to have site-specific hacks detracts from the general usability of the code.

So when simplifying, it's not just important to say "we could do without this". You have to also say "and nobody can reasonably expect to need it".

Which doesn't seem to be the case with /dev/ports. So it stays.

Linus

Uz.ytkownik Linus Torvalds napisa?:

"I will submitt my dual 8255 PIO ISA card driver from 1.xx days immediately for kernel inclusion"

This was the exmaple I had in my mind as I wrote the above. Slow controll means in experimental physics - controll of devices which don't have hard real time constrains. Once in my life I wrote a driver for such a beast which was controlling an experimental tomography device. But I have found it specific and trivial enough to don't bother to submitt it to the general public. It was *trivial* to implement becouse I could trick the LP driver to do what I wanted by deleting most of the code in it.
I assume that this kind of application is what Pete was talking about as he was speaking about "quite frequently" and finally "Solaris does without it so we could as well".

This was what I had in my mind with the advantage of having full access to the source code of the system. I certainly don't buy myself in the philosophical zealots view of of open source OS supreriority quite frequently propagated here by some individuals.

And please note even at the time then I didn't write the application by using the cards from user land directly - I just wrote the damn driver for it, becouse the "cheating" smelled to me immediately.

What I'm saying is: It has already caused people who write applications to control things like the system clock settings or keyboard speed to write the applications in a way which:

1. doesn't use the proper system interfaces,
2. is attracted to the particular hardware implementation
3. is inherently not portable across different systems. (Alan got this wrong).
4. a damn comon thing to do.

As a consequence of this it has caused the system
interfaces for those purposes to never mature.
USB keyboards to name one.

The single only guy who wanted to use it for some sane purpose and had some serious intentions about it noticed immediately that it is BTW seriously broken from day one on!

So in regard of the above I have decided for myself that the sanest way to fix it is to remove it.

I think one doesn't have only to provide things. One has to prevent damage as well. And hwclock and kbdrate are seriously damaged already for example. Once just didn't notice until now becouse it all kind of "works". Please look at the code there.

If you reffer to MS as a success story of about how to be a bitch to everybody ... well please tell me: Why do we use page protection for example at all. The implementers of DOS where not even dreaming about it and Win98 didn't care. All of the follow up operating systems from Redmond are making it seriously difficult to get direct hardware access. For scincetific applicatons there are even some special third party expensive drivers out there which are supposed to permitt just that - port access from user space.

This is one of the reasons I did implement the host controll software for the tomography device under Linux and NOT any windows or doors system. And it was in fact the first Linux in experimental medicine around there! (The circle was quite wide those days...)

Please do *grin* I will probably have to write a driver for just such a card (a PC104 card though, but that's just a differenct connector), so I'd love to have such a driver. And as long as the driver is self-contained and doesn't mess with other parts of the kernel I can't see why it shouldn't be included in Linus' tree. The same is IMHO true about /dev/port, it's rather self-contained and is less than 50 source lines in mem.c. It may be ugly but it's useful for some people.

/Christer

"Just how much can I get away with and still go to heaven?"

I used it for I2C on VGA cards and different ISA devices, and flash programming. Remember that though ISA went away on desktop, embedded people still use it. It was just FYI - if you persuade Linus to strike /dev/port down, I am not going to shed many tears, only a little :) It may be different for users of languages other than C, but let them defend themselves.

-- Pete

The 8255 is way too flexible for a single driver to be possible, IMHO. Also, it is used in devices which plug into a variety of upstream APIs, which makes the factorization not worth the effort. E.g. what if you have 8255 driving a 9 track tape and 8255 driving HP-IB bus? I think it would hardly be reasonable to unify those. OTOH, If Martin submits a header file with register breakdown, it may be useful (unlike a continuation of /dev/port discussion).

-- Pete

Uz.ytkownik Pete Zaitcev napisa?:

Well I wasn't serious about this submission thing precisely for the above reasons. From long past times I can remember that those beasts could be configured to have A B C D or whichever ports, which could be neraly infinitely permuted to provide many not usefull combinations of 4 or 8 bit bus buffers.
The externall visible register address or data lines where very likely to be permutted between the chip and the data part of the ISA bus, just becouse the layouter of the card did feel like beeing creative. (So even register values won't help you!)
And last but not least they could be coupled in bunches.
So the chances for a genrically usefull driver are indeed not big.

And last but not least: The source for a driver for a 1.0.xx kernel isn't very usefull nowadays.
And admittedly, well most lekely I don't have the code around any longer... but it was just about 400 lines I can remember.

COMEDI is the way to go for things like these. So if you want to make a driver for your device you should subscribe the comedi mailing list first and look if anybody has already done the work for you.

Robert

 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+