bing@galbp.LBP.HARRIS.COM (Bing Bang) (07/27/87)
Yesterday I modified ioctl.c (I wrote a serial tty driver)
and replaced it in libc.a by doing:
ar r libc.a ioctl.s
When I tried to cc a program that called ioctl, however, it failed to locate it
in libc.a. But I could extract it from the file with ar. Is this a known
problem? How would I get around it? Build the whole library?
--
Bing H. Bang +-------------------+
Harris/Lanier |MSDOS: just say no.|
Atlanta GA +-------------------+ast@cs.vu.nl (Andy Tanenbaum) (07/28/87)
In article <310@galbp.LBP.HARRIS.COM> bing@galbp.UUCP (Bing Bang) writes: >Yesterday I modified ioctl.c (I wrote a serial tty driver) >and replaced it in libc.a by doing: > > ar r libc.a ioctl.s > >When I tried to cc a program that called ioctl, however, it failed. The linker is a one-pass linker, so you can't have forward references. If procedure x calls y and z, x must appear in the library before y and z so that after loading x asld will know that it needs y and z. (I presume you compiled with the -LIB option, which is needed). Unfortunately there is no easy way to insert a module at an arbitrary place. You have to dismember the archive, and then build a new one from scratch using ar r newlib.a file1 file2 file3 ... There should be an option to ar so you could say: ar rb module libc.a file1 to replace before 'module'. Any volunteers on this one? If you have a serial line driver that works, please post it. There will be a lot of interest. One was posted earlier, but that one is not fully debugged. Andy Tanenbaum (ast@cs.vu.nl)
bing@galbp.LBP.HARRIS.COM (Bing Bang) (07/29/87)
>to replace before 'module'. Any volunteers on this one? > >If you have a serial line driver that works, please post it. There will be >a lot of interest. One was posted earlier, but that one is not fully debugged. > >Andy Tanenbaum (ast@cs.vu.nl) I am about ready to post the serial tty drivers, however there are some points I'd like to discuss. First off, the driver is not very V7ish. Things like waiting for carrier detect and raising and lowering of DTR is done through specialized ioctl calls, instead of them being implied by openning and closing the device. How acceptable is this? Second, I made many changes to the way fs talks to the device drivers and the way messages are passed in general. Fs now assumes every driver sends back a SUSPEND message as soon as it receives a message. To do this with out causing a deadlock condition, I changed the message passing scheme so that the sender is never blocked. If the receiver is not waiting, a slot out of a system message buffer pool is allocated, the message copied in to it, then the buffer is queued to the receiver's que. This change results in a kernel that is much more multi-tasking. I can now X-OFF my console and the stuff on the background keeps running. Now, I can post all of these changes if there is enough interest, or I can post a fixed version of the tty driver that will work with the standard fs. Oh, I haven't had time to merge any of the 1.2 kernel changes yet, a task I am not looking forward to, since I want to preserve my own hack too... oh yea I am still looking for the source to login.c and part 7 (of 7) of the new sh diffs -- Bing H. Bang +-------------------+ Harris/Lanier |MSDOS: just say no.| Atlanta GA +-------------------+
ast@cs.vu.nl (Andy Tanenbaum) (07/30/87)
In article <328@galbp.LBP.HARRIS.COM> bing@galbp.UUCP (Bing Bang) writes: >> >I am about ready to post the serial tty drivers, however there are some >points I'd like to discuss. >First off, the driver is not very V7ish. >Second, I made many changes to the way fs talks to the device drivers and >the way messages are passed in general. > I can post all of these [changes] ... or I can post a fixed version of the >tty driver that will work with the standard fs. > I am not at all enthusiastic about major surgery to FS to accommodate a new tty driver. One of my hopes in splitting FS off from the kernel was to prevent changes in drivers from requiring changes in FS. For another reason, the Atari version of MINIX is almost done, and changing FS in the IBM version will require either (1) changing the Atari version (no time for that), or (2) having the IBM and Atari file systems different (not appealing). Futhermore, I have frequently resisted the urge to "improve" on V7 on the grounds that a consistent V7 is better than a weird mixture of V7, Sys 5 and 4.x. Conclusion: I would much prefer the tty driver that works with the existing FS and makes as few changes as possible to parts of the system outside of tty.c. Andy Tanenbaum (ast@cs.vu.nl)