Subject: Linux-Development Digest #560 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Thu, 17 Mar 94 10:13:11 EST Linux-Development Digest #560, Volume #1 Thu, 17 Mar 94 10:13:11 EST Contents: Re: [Possible bug?] rm * on write-protected dos floppy (Johannes Stille) Driver for precise delays: Driver etiquette? (Byron A Jeff) DOS Emulator TCP/IP interface ? (Reuben Wells) Re: 127.x.x.x (was Re: UDP report card) (Charles Hedrick) SLIP, sl0 accounting (Arsenio Monteiro dos Reis - lisbbs SU) Re: 127.x.x.x (was Re: UDP report card) (Matthias Urlichs) IPX compliancy? (Mr Ivan Alastair Beveridge) Re: Amiga FileSystem, Anyone? (Kevin Brown) Re: DIP: tty: getc: I/O error (Kevin Brown) Re: VT's must all use the same font [was Re: Loaded fonts discarded aft] (Kevin Brown) Re: [Q] Unixware filesystem? (Michael K. Johnson) ---------------------------------------------------------------------------- From: johannes@titan.westfalen.de (Johannes Stille) Subject: Re: [Possible bug?] rm * on write-protected dos floppy Date: Wed, 16 Mar 1994 20:24:01 GMT In article <2m39g4$iss@wsdnws.cfi.waseda.ac.jp> 63912i@cfi.waseda.ac.jp ("Alexander During") writes: >In article <2m1q0r$627@wswiop05.win.tue.nl> koen@wswiop05.win.tue.nl (Koen Holtman) writes: [...] >> >>The Linux floppy drivers do not report write errors to the writing >>program. This is more a case of broken-as-designed than an actual bug. >>A real fix probably won't happen in the near future. >> >>> ---- Paul J. Gans [gans@acf2.nyu.edu] >>Koen. > >I wonder whether there could be done something about this. Suppose you [...] Perhaps you should pay more attention to this newsgroup. The problem is already solved. If you need details, please mail me. I won't waste bandwidth by posting the patch again after just two weeks. Linus has the patch, and I hope that it qualifies for the next kernel release. BTW, the patch I posted back then had a bug left , so if you have problems with it, please mail me. (Don't worry, it won't eat your disks, at worst it could prevent floppy access.) Johannes ------------------------------ From: byron@cc.gatech.edu (Byron A Jeff) Subject: Driver for precise delays: Driver etiquette? Date: Wed, 16 Mar 1994 23:07:28 GMT A few days ago I posted a question concerning writing a device driver for doing precise delays for a hardware programmer I'm building. I got a couple of replies saying use more hardware for the delay but doing it precisely will take up more space than I'm willing to give. Also I'm really interested about learning about device driver development so this is a real opportun- ity for me. I'm doing it as a device driver because I need to turn off interrupts and I ran a test program to try that as root (in user space). Didn't work. Also the kernel usleep function call is only accessible from kernel space. Anyway I've read the Kernel Hackers Guide and the source code and I have some more questions: 1) As I asked the last time what will be the effect of having uninterruptable 100 uS delays for the rest of the system? Will anything break? The max delay I saw in any other driver was 30 uS. 2) Do kernel space routines usually run with interrupts masked or unmasked? 3) If I cli() is there any exception in normal use that will interrupt a process that is running between a cli() and an sti()? 4) What is the proper etiquette for doing init? For the character drivers mem_init seems to have all the init calls for the other character drivers. Would is be acceptable to hook my delay_init there? 5) Am I correct in assuming that the register_chrdev actually hooks your driver to the rest of the kernel? The guide isn't real clear about that. 6) I know that for my own purposes that I can select a major number. However is there a process by which a major number can be assigned if this driver is of any use? 7) Dumb question: Why wasn't 7 assigned as a major number? Now for the actual driver. - character driver. - init, open, write, and close implemented. - doing a write will activate a hardware line on my programmer card, delay for 100 uS, then deactivate the hardware line. - The activation, delay, and deactivation will be done atomically by turning off interrupts. One issue that I see is that I'd like to control the flow of the delays so that the system doesn't crawl to a halt while programming. Three ideas come to mind: - Use one of the PC hardware timers. the 8254 (or equivalent) has 3 timers. Does Linux use all three? If not can I intercept one, program it for 100 uS delays and generate an interrupt. However latency could be a problem because that line needs to be activated for 100 uS +- 5 uS. Otherwise I get magic smoke from my devices ;-) - Somehow regulate the number of writes that can be done in a second. The problem I see (and is a real hinderance to real-time programming under linux) is that the jiffie clock is 100 Hz. Is it possible to specify a sleep of less time then 10 ms? I figure if I can get about 2000 writes per second will take %20 of the available time. But I need to be able to sleep for 400 uS between writes. - Instead of using the hardware timers to spcify the delay, use them to give the inter-write delay. So a write would do a uninterruptable usleep between wiggling the hardware line followed by a interruptable sleep after turning on the timer that will interrupt after 400 uS or so. Since the inter-write time is not critical if it's late (due to interrupt latency) it's no problem. Anyway I'm thinking that this might be a good example of a simple (very simple) device driver and can show the minimal elements needed for a device driver. Any comments? Keep it out in the newsgroup so we can all talk about it. BAJ --- Another random extraction from the mental bit stream of... Byron A. Jeff - PhD student operating in parallel! Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu ------------------------------ From: row@bnr.co.uk (Reuben Wells) Subject: DOS Emulator TCP/IP interface ? Date: 17 Mar 1994 08:50:58 GMT Hi, Is there a command based interface to the DOS emulator via TCP/IP ? The reason is simple, I have some commercial DOS programs (a compiler and assembler for a microprocessor) and I want to be able to use these from Linux and X. These programs only input and output text. I would like to be able to start the DOS emulator on a socket at boot time. I can then write wrapper Unix programs that connect to the socket, cd to the correct directory and invoke the programs returning the result. Why ? This has the illusion that the programs are just normal Unix programs and allows the use of tools like make. I can run them in any window and don't have to keep moving between the DOS emulator and the X-term I am working in. Also because it is always running it is not necessary to have to wait for DOS to boot each time a command is sent. I am sure this must be relatively simple to do :-) Any idea/pointers would be welcome, Thanks, Reuben ---------------------------------------------------- Reuben Wells (row@bnr.co.uk) Research Engineer BNR Europe, London Road, Harlow, Essex, CM17 9NA Tel: +44 (279) 403014 Fax: +44 (279) 402047 ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Crossposted-To: comp.protocols.tcp-ip Subject: Re: 127.x.x.x (was Re: UDP report card) Date: 17 Mar 94 05:04:42 GMT longyear@netcom.com (Alfred Longyear) writes: >So, it is not the "implementation of TCP/IP" which is broken, but the >operator's setup of the TCP/IP configuration which is broken. There is nothing >"magical" about the address 127.0.0.1 other than the convention that it is the >loopback device and is normally _configured_to_route_ back to your own machine. Actually, there is something magical about 127: RFC 1122 and RFC 1009 both specify that 127 is a bogus address, and must never appear in a packet that goes out of your machine. ------------------------------ From: arsenio@uc.pt (Arsenio Monteiro dos Reis - lisbbs SU) Subject: SLIP, sl0 accounting Date: Thu, 17 Mar 1994 09:46:46 GMT Hi, i am managing a slip server, it has only one line, so all my clients share the same ip adress, i would like to have a log reporting the trafic on the sl0 interface, so i could know each user traffic, could someone point me out some guidelines on how to do this? where in the kernel src is the code regarding sl# interface, etc. Thanx. -- _ /_| / |rsenio Reis arsenio@lisbbs.uc.pt Laboratorio de Informatica e Sistemas Quinta da boavista lote I, 1 3000 Coimbra /---------------------------------------\ Portugal < Living in a box, a Linux Box. > \---------------------------------------/ ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Crossposted-To: comp.protocols.tcp-ip Subject: Re: 127.x.x.x (was Re: UDP report card) Date: 17 Mar 1994 12:03:30 +0100 In comp.os.linux.development, article <2m6g6r$ijk@gap.cco.caltech.edu>, heathh@lust.ugcs.caltech.edu (Heath I Hunnicutt) writes: > > The difference is that the IP layer can make the correct decision not to put > anything to 127.* on any external interface. The idea that someone should > need to configure their system to not violate the RFCs is ridiculous. There > is a large responsibility on the part of the stack to not allow stupid things > like sending 127.* out on the net. > You can do a lot of stupid RFC-violating things with your network configuration (and other parts of the kernel) that the fact that the kernel doesn't regard 127.* as special doesn't bother me. With newer BSD networking code, the fix is easy; just add route add -reject -netmask 255.0.0.0 127.0.0.0 127.0.0.1 to the startup script. Voila, no more 127.* packets getting out. > You really should research these issues before posting. For starters, see > the Hosts Requirements RFC. There is indeed something "magical" about any > address on the 127 net. Whether you set your system up with 127.0.0.1 as a > loopback or not is your problem. No matter what, you should never send > packets to 127.anything out any interface, regardless of the routing table's > (mis)configuration. Given that I've not heard of anybody who gets hurt by seeing spurious 127.anything_but_0_0_1 IP or ARP packets on the wire, I don't think special code in the kernel to catch that case is all that necessary. Not if it can be caught by a simple routint table entry. -- A woman of generous character will sacrifice her life a thousand times over for her lover, but will break with him for ever over a question of pride -- for the opening or the shutting of a door. --Stendhal -- Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. 90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Click here. ------------------------------ From: zceed04@ucl.ac.uk (Mr Ivan Alastair Beveridge) Subject: IPX compliancy? Date: 17 Mar 1994 04:57:42 -0600 Basically, I was wondering if anyone has made Linux compliant with Netware at all. As I do not really know much about protocols, I cannot really ask much more than this. Cheers Ivan -- Ivan Beveridge ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Amiga FileSystem, Anyone? Date: Wed, 16 Mar 1994 21:35:29 GMT In article <5Kh9LndjcsB@khms.westfalen.de> kai@khms.westfalen.de (Kai Henningsen) writes: >dholland@husc7.harvard.edu wrote on 10.03.94 in : > >> I believe the original point here was that DOS has no real workable >> mechanism for handling alternate filesystems. I don't think the > >This, of course, is plainly wrong. > >> existence of the network redirector qualifies, because it's obscure, >> messy, not necessarily supported, and still limits you to 8+3 >> character filenames, and various programs randomly don't work with it. > >1. Obscure & messy noes not mean it's not real workable. >2. What do you mean, "not necessarily supported"?! >3. *Of course* you are limited to 8+3 - that's DOS's *concept* of a >filesystem. Umm...then exactly what do you mean by "DOS handles alternate filesystems"? Exactly what do you mean when you say "filesystem"? I usually think of a filesystem simply as a mechanism for file storage. You have some minimum set of operations (open, close, read, write, seek, remove) that you can perform on it. Anything that doesn't at least support that basic set of operations is not what I would consider to be a filesystem. Everything else is effectively variable: filename conventions, block size, directory layout, block allocation mechanisms, etc. If you can support the above set of operations on, for instance, tar archives, then you can legitimately claim that a tar archive is a "filesystem". To me, then, the claim that some piece of software (I won't go so far as to say that DOS is an "operating system", but we've been through this before) supports "alternate filesystems" implies that it supports variability in the things that define the implementation of a filesystem. Linux has true alternate filesystem support, in that it leaves it up to the filesystem implementation to define such things as filename conventions, block allocation, directory layout, etc., and just defines the API you use to access the filesystem. DOS doesn't do this, if it defines what filenames are to look like (what *else* do they define for you?). At best, one can say that DOS provides partial alternate filesystem support if, for instance, it doesn't insist on defining things like directory layout, block allocation, or other filesystem-dependent attributes. Regardless of the details, I suspect we all agree that the alternate filesystem support in DOS is suboptimal, at least when compared to the support found in (for instance) Linux. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: DIP: tty: getc: I/O error Date: Wed, 16 Mar 1994 21:47:37 GMT In article <1994Mar13.140017.293@ijssel.hacktic.nl> arnoudm@ijssel.hacktic.nl writes: >Sys admin writes in newsgroup comp.os.linux.development: >> * No gettys on the serial ports * >> When I first boot my machine, I can run kermit as much as I want with no >> problems. My first DIP script runs fine, but when I kill DIP >> via kill -9 pid, > >Sys admins who complain about a system failure when they kill a >system program with -9 signal should be forced to read a goood >Unix book. Ever heard of proper clean up? Read the man-page: Dip >provides the -k option which lets dip to do it's own clean up >(even hangup the line). Yup. However, user programs (i.e., those programs that are required to go through the appropriate kernel calls to get to the filesystems and to the hardware) should never be able to hose the system to the point of requiring a reboot. More to the point, even if the serial port is in a weird state, the administrator should still be able to log into the console and set the serial port to a sane state. The kernel shouldn't lock up just because the serial port is in a weird state. Of course, that's how things *should* be. I realize that such ideals are difficult to achieve in practice... >> enter kermit, enter hang command to hang up modem, I have to re-boot! >> DIP now gives me the error in the subject, or sometimes it hangs when setting >> the port to ttyS0. Kermit starts, then hangs untill I enter CTRL-C, which >> brings me to the kermit prompt. When I enter 'connect' I get >> Kermit -> Can't send character: I/O error. > >I am not sursprised. Me neither. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: VT's must all use the same font [was Re: Loaded fonts discarded aft] Date: Wed, 16 Mar 1994 22:26:22 GMT In article hpa@nwu.edu (H. Peter Anvin) writes: >In article of comp.os.linux.development, > aeb@cwi.nl (Andries Brouwer) writes: >> >> You asked this question before, and I answered it. Now you ask >> it again, and the answer will be the same. >> Several implementations of font loading code were floating around, >> and I liked Crosser's version best, polished it a little and proposed >> including it in the standard kernel, which Linus did. >> [So, no behaviour was changed, but a choice was made.] >> >> Now should there be a separate font for each VT? >> If everyone wants it, then yes. If many people want it, then >> it should at least be a configuration option. Actually, it shouldn't be a matter of choosing to have one variable font for all consoles or support for separate fonts for each console. Rather, the console code should reuse fonts that are already in use, which means that font identifiers will need to be used, but that shouldn't add much more overhead (only a few bytes) than what you'd have if you were using a single loadable font for each console. The data for the font would still dominate in the space usage calculation. So if console 2 and console 1 are using the same font, then that means that their font entries point to the same font structure. Your font structure keeps a unique ID (perhaps the path to the font? Something that you can use to detect whether font change requests refer to the cached font or to some other font) and a reference count, and when it goes to zero, you can free it up (or mark that area for reuse by another font when you go to load a new one). Ideally, the font structure should simply contain the unique ID, the reference count, and a pointer to the actual font. That way, you refer to the ROM-based font by having the font structure's pointer point to it. I haven't looked at the console source, so I can't say whether it's possible to implement the above scheme. But if it is, then that's how it should be done, IMHO. It buys you the efficiency and relatively low overhead of a single font in the case that the *user* doesn't want to have different fonts for each console, and gives you the flexibility of having separate fonts for each console if that's what the user wants. >> But there is a danger of pollution: there are many potentially >> nice things, and at configuration time one could easily have >> fifty keyboard/console-related questions. Nope. With the above, one simply asks "do you want loadable console fonts?" and configures things appropriately. Indeed, I would think that *not* configuring loadable fonts basically means that the code for loading fonts isn't compiled in, but the font structure remains for the purposes of initializing the consoles to point to the ROM-based font. In short, it shouldn't save you *that* much to begin with. You could thus easily justify making the loadable fonts module the default option. >> Separate fonts for each VT take a lot of memory, and are used >> by relatively few Linux users, so cannot be the default, I think. > >Two issues: > >1. I would assume support could be there; memory could me kmalloc()ed >at load time if the font is loaded with the "set only this VT" option. >Since the maximum size of a font is 32x256 = 8K, having two data block >pointers/VT would do it. If set to NULL, use the global font. As per above, any font should be usable by any set of consoles. There shouldn't be a distinction between a "global font" and a "font only for this VT". If anything, the only font that should get special treatment is the ROM font. It would be ideal if the ROM font could be treated as any other font (except that, at boot time, its reference count is set to 1 + NR_CONSOLES and all consoles are initialized to point to its font structure, in order to insure that it is impossible to cause its reference count to drop to zero even when all consoles are actually using RAM-based fonts). -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: johnsonm@ladybird.oit.unc.edu (Michael K. Johnson) Subject: Re: [Q] Unixware filesystem? Date: 16 Mar 1994 01:04:21 GMT In article hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP) writes: In article <2m25ee$iv4@cville-srv.wam.umd.edu> of comp.os.linux.development, barspi@wam.umd.edu (Barzilai Spinak) writes: > After 1 1/2 years of waiting, I will shortly have a BIG computer and > will install Unixware, Linux and Windows (ugh! ...I need to). My question > is if there's a Unixware filesystem the Linux can use. I don't know anything > about Unixware yet and I don't know if it uses a proprietary filesystem > or not. Unixware probably uses either UFS or the SysV filesystem. Linux supports the SysV filesystem; it does not support UFS. Unixware, by default, uses the Veritas filesystem, which is a log-structured filesystem with extremely good crash recovery. I have only once ever seen a veritas filesystem come up so much as dirty after a crash, and that once, a simple fsck didn't even have to do any corrections to the filesystem -- just marked it clean. And I have seen plenty of hard crashes on unixware machines running veritas -- device driver development... Unixware does also support other filesystems, including UFS and SysV, but the SysV filesystem it supports *is* limited to 14 character filenames, (of course), and so is of limited use. As Peter pointed out, it's the only filesystem in common, though. michaelkjohnson ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************