506 lines
21 KiB
Plaintext
506 lines
21 KiB
Plaintext
Subject: Linux-Development Digest #565
|
|
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
|
|
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 <CMrHE1.FCH@murdoch.acc.Virginia.EDU> 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 <rogers@drax.isi.edu> writes:
|
|
|
|
CMR> In article <DMW.94Mar15101043@prism1.prism1.com> 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 <robertl.762402975@amsg>,
|
|
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 <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
|
|
|
|
------------------------------
|
|
|
|
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 <file_to_print >/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 <jfh@rpp386.cactus.org> 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
|
|
******************************
|