Date: Fri, 28 Jul 1995 17:10:16 -0400 From: dennis@et.htp.com (dennis) To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@freebsd.org Subject: RE: ioctls() and O/Ss Message-ID: <199507282110.RAA21114@mail.htp.com>
next in thread | raw e-mail | index | archive | help
>> UNIX is an abortion. All O/Ss are abortions. There is no clean way to design > >Well, yes, but now we're expanding the topic a little too widely.. :-) > >> it to do. The wost thing is if you have to redesign the internal structures >> every time something >> new comes along. ioctls() allow you to design portable interfaces without >> having to change the O/S. > >Oh YUCK, no they don't! You still need to hack the OS to get the >whatever driver it is you're working on to see the new ioctl, and then >you need to beat on the header files to get the new ioctl() define >registered in user space. That's one of the reasons I hate the whole >mechanism - it's crude! You shouldn't have to if you set aside enough slots for driver-specific commands. what I was referring to was that "existing" drivers can be used with any O/S with the common ioctl mechanism. We have the same driver calls for DOS.WINDOWS, System V and BSD. In BSD we have to stuff them in an ifreq structure, in System V a STREAMS message, and in DOS and Windows a mini carrier structure. Buts its all the same base code. Remember that people don't use an O/S because its a better O/S, but because more things are available and run well in a particular O/S. If you create an environment that makes porting drivers difficult then you are at a disadvantage. Very few vendors have the expertise or resources to write custom drivers for small market O/Ss like BSD unix, and as you're finding out you can't do everthing yourself either. db
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507282110.RAA21114>