Subject: Linux-Development Digest #565 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Sat, 19 Mar 94 16:13:08 EST Linux-Development Digest #565, Volume #1 Sat, 19 Mar 94 16:13:08 EST Contents: Re: Future development of Linux and affects on other architectures (Eric Youngdale) Re: Real-Time Linux and a/d device drivers (Matthew Donadio) Re: Specialix Driver Round 2 (From specialix) (David Wright) How stupid dos is [was Re: Amiga FileSystem, Anyone?] (Hamish Macdonald) Re: Controlling terminal = console? (Orest Zborowski) Re: A truely non-debugging Kernel? (John F. Haugh II) Re: VM performance tuning via program restructuring (John F. Haugh II) Re: Annoying interactive bug in nslookup? (Matthias Urlichs) Printer Problems -- ANSWERS (Ken Kopilevich) Re: A truely non-debugging Kernel? (Linus Torvalds) blank_screen patch for Laptops (Questions) ("Alexander During") ---------------------------------------------------------------------------- From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: Future development of Linux and affects on other architectures Date: Sat, 19 Mar 1994 16:18:38 GMT In article doolitt@cebaf4.cebaf.gov (Larry Doolittle) writes: >> "inline function" or a preprocessor macro, and keep the definition of >> the inline function or macro separate from the main functionality. > >... When you do, it should take the form: >#ifndef i386 > simple { > c; > substitute(); > } >#else > high > speed > assembly > hack >#endif If we get ports to multiple architectures, this type of coding could be quite difficult to read. Instead I would suggest that the macros or inline functions be stored in the header files in include/asm. Ultimately there will need to be separate asm directories for i386 and other machines, so you would merely set up a link to the right directory and you would get the right functions. There could also be some kind of "generic" directory for the C equivalents. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ From: donadio@mxd120.rh.psu.edu (Matthew Donadio) Subject: Re: Real-Time Linux and a/d device drivers Date: 17 Mar 1994 17:09:07 GMT Scott McClung (mcclung@squire.chinalake.navy.mil) wrote: : Have I gone off the deep end to even ask these questions? I doubt that : many of us need a RTOS, but it would be neat anyway... The people that neet real-time probably also have the money for something like LynxOS or QNX and also have the money for a better architecture like VME.... Seriously, what I would like to see is kernel level threads. Pthreads exists right now, but only on the user level. Does anybody out there know anythings about how hard this would be to implement? I don't know much about kernel stuff (just a little about drivers), so I'm not one to begin work on it... -- Beaker aka Matt Donadio | Life is short, --- __ o __~o __ o donadio@mxd120.rh.psu.edu | ride like ---- _`\<, _`\<, _`\<, --- Penn State Cycling ---| the wind. --- ( )/( ) ( )/( ) ( )/( ) ------------------------------ From: dmw@prism1.prism1.com (David Wright) Subject: Re: Specialix Driver Round 2 (From specialix) Date: 17 Mar 94 14:22:19 GMT >>>>> "CMR" == Craig Milo Rogers writes: CMR> In article dmw@prism1.prism1.com (David Wright) writes: >> Very clearly the portion that actually "hooks into" the OS would be >> covered by the GPL, and not one of the developers has said they have a >> problem with that. CMR> Not true. On 28 Feb 94, in message , CMR> Robert Lipe, head code-layer for Arnet (his phrase), a "ports board" CMR> company, speaking unofficially but apparently referring to some of his CMR> company's products, said: CMR> "As proprietary as these executables is the CMR> interface as to how a programmer talks to them." CMR> In context, "executables" refers to the onboard code, and CMR> "interface" is the hardware interface used by the host computer's CMR> operating system device drivers. Thus, since they do not wish to CMR> reveal the host-side interface, a GPLed OS device driver is CMR> unacceptable to them. I don't see that the "host side" portion of the code would be vendor-specific in & of itself. Granted, as there is no "generic" intelligent host adapter "glue" code right now (that I am aware of), someone would have to write this (which would be covered by the GPL), possibly using the standard serial device interface code as an example (which is how you want the intelligent card to look for IOCTL purposes anyway). But that does not have anything to do with the code that is running ON THE HOST ADAPTER. IE: If the host adapter is using a RISC procoessor, all the Linux code is doing is acting as a loader for the RISC code, and the RISC code would NOT be under the GPL at all. What would be good to have (and what we will get "de facto" when the Specialix driver is released) is an API for talking to intelligent cards under Linux. This would be the part that got linked into the kernel, that knew about Linux internals, and how to write to the intelligent card on the other side. What the intelligent card DOES with the data would still be vendor specific, and would be running vendor-supplied binary code (either loaded by the drive at boot time (the loader would likely have to be GPLed), or on firmware on the card) that would NOT have to be GPLed, since it knows nothing about Linux/Unix/DOS at all... CMR> If you are a latecomer to this thread, I might be able to CMR> email you a copy of the messages that I've saved from it. Nope, I have the whole thing here, and saw all the various "rounds"... Dave -- ____________________________________________________________________________ | /\ / | Prism Computer Applications | David Wright | | -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM | | /____\ | Lakewood, OH 44107 USA | 216-228-1400 | ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Subject: How stupid dos is [was Re: Amiga FileSystem, Anyone?] Date: 19 Mar 1994 16:53:53 GMT Can we change the subject of this thread, please? ------------------------------ From: orestz@eskimo.com (Orest Zborowski) Subject: Re: Controlling terminal = console? Date: Fri, 18 Mar 1994 09:35:59 GMT John Shifflett (jshiffle@netcom.com) wrote: : I have a program that would like to know if it's controlling terminal : is one of the virtual consoles or not. I looked for, but could not : find, an ioctl call that passed this info back. Did I miss something? : At this point, I am doing a 'ttyname(0)' and checking the result : to see if it's "/dev/tty0", "/dev/tty1", etc. This works, but seems : clunky, and possibly not very portable. Can someone advise me? : Thanks.... : John S. jshiffle@netcom.com I've seen this sort of technique used on other OS's, and it's not really unportable under Linux, as long as people don't rename their console devices. A better method would be to use one of the VT-specific ioctls, like KDGKBTYPE, which returns the current keyboard type. It will fail unless the target tty is a console. Check out /usr/src/linux/drivers/char/vt.c. -orest ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: A truely non-debugging Kernel? Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Sat, 19 Mar 1994 15:35:48 GMT In article <2mck13$f96@liberator.et.tudelft.nl> wolff@tardis.et.tudelft.nl (Rogier Wolff) writes: >Problem is that bugs show up when you least expect them. If checks are made >all over the place you will also catch errors before they become critical. Yes, but none of this argues against using #ifdef to compile out the code. If a kernel runs fine for a month, isn't it time to assume that the same kernel will run fine for ANOTHER monther and even faster if you remove all the checks? You are looking at this wrong -- if you assume the kernel is going to crash all the time, you pay the penalties when it doesn't. AND, the user has no choice in the matter. -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: jfh@rpp386 (John F. Haugh II) Subject: Re: VM performance tuning via program restructuring Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Date: Sat, 19 Mar 1994 17:29:33 GMT In article <2me7in$q02@senator-bedfellow.MIT.EDU> gkm@tmn.com (Greg McGary) writes: >Conceptually, the project is simple and has these three elements: > >1) A profiler that's capable of gathering usage statistics at a level > of granularity no coarser than the function. (Actually, you won't > want to go any finer than that either. It would be a nightmare to > introduce the possibility of rearranging the basic blocks of a > function to be in different pages depending on their usage.) > The simplest approach, which also gives the most bang for the least > buck, is to do simple call counts. Call counters aren't quite right for this. They assume that each function call takes the same amount of time. What you want is the PC profiling samples. Convert the counters to function names, sum all the counters, and sort. The resultant order is the loader order. Call counters will tell you that an entry point is referenced a lot, but not if the pages in that function are. Using the total time per function tells if that the pages in that function are referenced frequently. The "prof" command with standard UNIX will give this information directly. Neither of these techniques will tell you locality of data references. For that it would be nice to get the pager to create paging logs for a process much the same way the clock tracks PC samples. How about a profil() like function which takes a user-defined array and increments a counter for each page fault? -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh@rpp386.cactus.org There are three documents that run my life: The King James Bible, the United States Constitution, and the UNIX System V Release 4 Programmer's Reference. ------------------------------ From: urlichs@smurf.noris.de (Matthias Urlichs) Subject: Re: Annoying interactive bug in nslookup? Date: 19 Mar 1994 19:52:05 +0100 In comp.os.linux.development, article <2m6uo6$ubh@smurf.noris.de>, I wrote: > > Actually, I'm using "dig". It can do everything that nslookup can do, > except zone transfers -- and these are better with named-xfer anyway. > OK, so dig can do zone transfers too (with the "axfr" keyword). It even returns the data in human-readable form... named-xfer returns the zone in machine-readable-but-comprehensible form, while nslookup returns bogus information (it skips the origin data, i.e. you never know which domain the returned names are in). Thanks to everybody who told me. -- Women and cats do as they damned well please. Men and dogs had best learn to live with it. -- Heinlein's "Notebooks of Lazarus Long" -- 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: kirill@crl.com (Ken Kopilevich) Subject: Printer Problems -- ANSWERS Date: 19 Mar 1994 10:00:08 -0800 Thank you to everyone who has answered. The following are e-mail from participating helpers. ************************************************************************* No need to post, I think. It's already available in PRINTING-HOWTO. It should cover you problem, and many others as well. Look into sunsite.unc.edu /pub/Linux/docs Hi, with all respect, Sir - RTFM !! Linux is not yet an OS aimed at the normal OS-user. It is not MS-DOS. You have to read all the documentation about everything that may concern You. In this case, look at the printing-HOWTO available on main Linux sites, such as: tsx-11.mit.edu sunsite.unc.edu ftp.funic.fi Good Luck ! Send the proper escape sequence to the printer and it will add the CR's. For my IIIP it is ESC & 2 G (blanks added only for clarity) as I remember, and is probably the same for yours. Check either the printer documentation or the FAQ on printing if it doesn't work. Gerry Snyder Read your Printer-HOWTO. If you don't know where it is, try typing in 'faq' in your linux box. James :) Yep, been there, done that. The very simplest way to fix this is to write a script (or other program) to replace the LF with a CR/LF. For example, you could use the 'lpf' filter below to do 'lpf /dev/lp1'. If you want a nicer solution, i.e. so you can do 'lpr', then you should read the 'Printing-HOWTO'. It's available as sunsite.unc.edu:/pub/Linux/docs/HOWTO/Printing-HOWTO (I think), and is posted every so often to comp.os.linux.announce. Here's an extract which covers the 'staircase effect', as they call it: 3.11 How to prevent the `Staircase Effect' ========================================== Un*x terminates each line of a file with a linefeed but not a carriage return so taken literally a Un*x text file printed on an ASCII device will start each line below the end of the previous line. Some printers can be set to treat "linefeed" as "carriage return, linefeed", others can't. If yours can then do simply do that. If the printer cannot be fixed create a shell script filter that reads: #!/bin/sh if [ "$1" = -c ]; then cat else sed -e s/$/^M/ fi # the ``echo -ne'' assumes that /bin/sh is really bash echo -ne \\f Where `^M' is a carriage return character not a `^' followed by a `M'. To type `^M' in Emacs use the sequence `C-q C-m' and in vi use `C-v C-m'. Conventionally this script is called `/usr/lib/lpf'. If you have more than one such script a better idea is to keep them in a subdirectory, say `/usr/lib/lpd/'. The test of `$1' allows the insertion of carriage returns to be switched off by `lpr -l'. Install this filter as the `if' filter by putting `:if=/usr/lib/lpf:' (or whatever) in your `/etc/printcap' entry for the printer. Alternatively your printer may have an escape sequence that will set the way it handles linefeed characters. A simple filter that uses an `echo -ne' command to send this sequence may be appropriate. #!/bin/sh # Filter for HP printers to treat LF as CRLF # the ``echo -ne'' assumes that /bin/sh is really bash echo -ne \\033\&k2G cat echo -ne \\f -Rus. Your printer should have an escape sequence that you could put in an initialization for the printer. It should be described in the documentation. I do not own this type of printer, but at work we have LaserJet IID's. I have found that HP generally keeps the escape sequences for similar features consistant. For the LaserJet IID, the escape sequence is: Line Termination: CR=CR; LF=LF; FF=FF \E&k0G CR=CR+LF; LF=LF; FF=FF \E&k1G CR=CR; LF=CR+LF; FF=CR+FF \E&k2G CR=CR+LF; LF=CR+LF; FF=CR+FF \E&k3G In your case, I think that you want the 3rd option. I believe that the solution to this is in the Printing-HOWTO. After I followed the instructions there, a similar problem on my Laserjet dissapeared. -- Robert Jones There are a bunch of solutions to your problem. The first thing is learn something about printcap and work with the filter to turn lf's into cr/lf's. There are already utilities out there that will do that for you, if you prefer that route. If you are a programmer, it will be easy. I wrote C source in about 10 mins with about 10 lines of code that took care of the problem, and it worked stupendously. Good luck and take care Steve ------------------------------ From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: A truely non-debugging Kernel? Date: 19 Mar 1994 21:35:20 +0200 In article <1994Mar19.153548.25480@rpp386>, John F. Haugh II wrote: > >Yes, but none of this argues against using #ifdef to compile out the code. >If a kernel runs fine for a month, isn't it time to assume that the same >kernel will run fine for ANOTHER monther and even faster if you remove all >the checks? > >You are looking at this wrong -- if you assume the kernel is going to crash >all the time, you pay the penalties when it doesn't. AND, the user has no >choice in the matter. I can only talk for myself: - I dislike #ifdef code. Avoid it whenever possible. #ifdefs become ugly, and destroy the linearity of the code (== hard to read). - I *do* assume the kernel is going to crash, and no, I don't presonally like the idea of letting the user easily shut down some of the sanity checks I write. Admittedly, they happen very seldom, and they have a tendency to stay in even after I trust the code, but you'd be surprised how many *hardware* bugs they've found. Note that especially the latter one doesn't matter in user-level code, but the kernel is rather special when it comes to debugging. If somebody feels safe about it, let him edit out the stuff by hand.. Linus ------------------------------ From: 63912i@cfi.waseda.ac.jp ("Alexander During") Subject: blank_screen patch for Laptops (Questions) Date: 17 Mar 1994 18:29:15 GMT Hello out there. After a horrible trip with sourcer through a DOS device driver for my laptop, I got my new 1.0 to switch off the backlight for the LCD screen in blank_screen() and back on again in unblank. So far, so good. Two questions remain. First, why is blank_screen() directly hooked to the blank timer and at the same time used by XFree 2.0 to clear the character buffer (or better, save it) at startup? The problem arising is XFree switching off the screen when it starts :-( I fixed this for the moment by checking for the expires field of the timer_table entry, but this seems kludgy to me (though it works unless you start X with at and are very unlucky). Couldn't be the actual timeout and the screen saving be separated, so special hardware hooks could just be compiled in? Next question: Those computers were sold a lot in Germany under various brands and I also saw a review on it in PC magazine. So I guess there are more of them out there and perhaps some- body else could have an interest. Could you please, if you own a laptop, check whether you used a driver named note3500.sys under DOS (not neccessary), have a key named 'Fn' in blue next to Left-Alt and some blue notes on the function keys, an Award modular BIOS, and feel you have this kind of machine (there are various models around, I have a 486DX2-50), tell me the name of the maker and the model name? I would like to make this patch available and give at least a short list of applicable computers. I will of course provide a command line program first, so you can check without a kernel patch (and having 10min to wait :-)). -- As MS-DOS is very abstruse, \\it's also quite tricky to use. \\So many give in and try typing 'win'. \\But that means completely to lose. Alexander D\"uring, Physics Department, Waseda University, Tokyo, Japan. Statistical Physics, Linux, Shakespeare. --- This space for rent --- ------------------------------ ** 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 ******************************