756 lines
30 KiB
Plaintext
756 lines
30 KiB
Plaintext
Subject: Linux-Development Digest #557
|
|
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: Wed, 16 Mar 94 08:13:06 EST
|
|
|
|
Linux-Development Digest #557, Volume #1 Wed, 16 Mar 94 08:13:06 EST
|
|
|
|
Contents:
|
|
Adaptec 2742T anyone? (David Rapchun)
|
|
Re: TTY overruns cost money. (Nemosoft Unv.)
|
|
Re: Amiga File System, once again (Hamish Macdonald)
|
|
Re: Amiga FileSystem, Anyone? (David Holland)
|
|
Re: YP or NIS for linux? (John F. Haugh II)
|
|
Re: YP or NIS for linux? (John F. Haugh II)
|
|
Re: A truely non-debugging Kernel? (John F. Haugh II)
|
|
Re: YP or NIS for linux? (John F. Haugh II)
|
|
Re: Amiga FileSystem, Anyone? (Kai Henningsen)
|
|
Re: DIP: tty: getc: I/O error (Christian Henry)
|
|
Re: Andrew 6.1 for Linux: who did it? (Doug DeJulio)
|
|
Re: TTY overruns cost money. (Kevin Lentin)
|
|
Fooling with the timer interrupt (Milind Paranjpe)
|
|
Fonts, keyboards, mice - a proposal (Jamie Honan)
|
|
[Q] Adaptec 2842 SCSI driver yet? (Mark Biegler)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: rapchun@suicide.sdsu.edu (David Rapchun)
|
|
Subject: Adaptec 2742T anyone?
|
|
Date: 15 Mar 1994 01:24:07 GMT
|
|
|
|
|
|
Hello, I understand there are some people working on writing a driver for
|
|
the Adaptec 7770 series chip. IE, the 2742 and 2842 both use this new chip.
|
|
I was just wondering how the work is coming along since I would really like
|
|
to run Linux soon. Thanx.
|
|
|
|
Dave.
|
|
|
|
--
|
|
*******************************************************************************
|
|
* rapchun@mintaka.SDSU.edu Dave Rapchun *
|
|
*******************************************************************************
|
|
|
|
------------------------------
|
|
|
|
From: nemosoft@void.tdcnet.nl (Nemosoft Unv.)
|
|
Subject: Re: TTY overruns cost money.
|
|
Date: Tue, 15 Mar 1994 02:56:03 GMT
|
|
|
|
In article <tgmCMLsoH.JF9@netcom.com> tgm@netcom.com (Thomas G. McWilliams) writes:
|
|
>Kai Petzke (wpp@marie.physik.tu-berlin.de) wrote:
|
|
>: However, if overruns happen on every single move with the mouse,
|
|
>: there should be something wrong with the kernel.
|
|
>
|
|
>The more likely problem is that the mouse was given a higher
|
|
>priority interrupt than the modem. The modem should always be
|
|
>given interrupt 3 if possible--this is naturally the case if you
|
|
>use /dev/cua1 for your modem.
|
|
|
|
Pardon ?? All interrupts are handled at the same priority... There's no such
|
|
thing as a precedence for modems on certain serial ports... I'm afraid your
|
|
confusing interrupts with i386 microcode priviledge levels, or something.
|
|
|
|
Anyway, my questions still stand: why is now all this attention payed to
|
|
some vague bit that tells me something is overrunning, while I obviously
|
|
loose no data, and why am I even bothered by them at 2400 baud ? That's
|
|
ridiculous. I've never seen any MS-DOS comm-program bitch about overruns,
|
|
not even at extreme high speeds like 115200 baud on an 8088 XT. And then I
|
|
didn't loose a single byte !
|
|
|
|
Why is it that the Linux serial drivers suddenly seem to be so broken down,
|
|
in comparison with this ? Maybe we should turn back to some good-ol'
|
|
assembler code ?
|
|
|
|
However, I credit you in 1 thing: support to share COMports on IRQs. But
|
|
even there things are weird. For example: my mouse for X is on ttyS6 (1200
|
|
buad) (COM7 *cheer*), using IRQ3. So is my modem at ttyS3 (2400 baud). Now
|
|
these combinations work or don't:
|
|
|
|
kermit on /dev/cua3, 2400 baud, 8N1 : mouse hangs.
|
|
uucico dial out on /dev/cua3, 2400 baud, 8N1 : mouse rolls happily
|
|
DIP on /dev/cua3, 2400 baud, 8N1 : DIP input gets eaten a bit
|
|
uugetty on /dev/cua3, 2400 baud, 8N1 : mouse hangs.
|
|
|
|
Now you find the differences, and tell me what's wrong. Note that the only
|
|
point where mouse & modem "meet" is in /linux/drivers/char/serial.c where
|
|
the interrupt handlers are. Even something simple as opening the device from
|
|
kermit will hang the mouse, then I'm not even 'c'onnected to it....
|
|
|
|
*seriously considers of throwing out this cereal.c and start from scratch*
|
|
|
|
- Nemosoft
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
|
|
Subject: Re: Amiga File System, once again
|
|
Date: 15 Mar 1994 04:18:11 GMT
|
|
|
|
>>>>> On 14 Mar 1994 05:07:37 EST,
|
|
>>>>> In message <ARMB.94Mar14100737@hamsta.setanta.demon.co.uk>,
|
|
>>>>> armb@setanta.demon.co.uk (Alan Braggins) wrote:
|
|
|
|
Alan> Are you saying both the Linux and AmigaDOS versions of the Amiga file
|
|
Alan> system will already work on PC-formatted floppies
|
|
|
|
Yes.
|
|
|
|
Most PC-format support programs on the Amiga (MultiDOS and MSH at
|
|
least; I'm not sure about cross-dos) allow the use of the Amiga
|
|
Fast Filesystem on a 720K floppy.
|
|
|
|
The Linux "affs" support should allow you to read the filesystem from
|
|
a 720K floppy, if you give "mount" the right options (size/root
|
|
block).
|
|
|
|
------------------------------
|
|
|
|
Subject: Re: Amiga FileSystem, Anyone?
|
|
From: dholland@husc7.harvard.edu (David Holland)
|
|
Date: 15 Mar 94 15:54:06
|
|
|
|
|
|
kai@khms.westfalen.de's message of 14 Mar 1994 23:54:00 +0100 said:
|
|
> > True. But it's not real workable as an easy general solution -
|
|
>
|
|
> That's because
|
|
> 1. DOS is single-tasking single-address-space
|
|
> 2. 640K is not a lot of memory for today's programs.
|
|
>
|
|
> There *is* no simple solution to these problems.
|
|
|
|
Yup...
|
|
|
|
> > Well, that's broken, and makes it impossible for DOS to really use
|
|
> > most other filesystems. :-)
|
|
>
|
|
> Hmm. Now, why have I seen DOS "use" lots of file systems that weren't 8+3?
|
|
> Of course, using various work-arounds, like only seeing some files, or
|
|
> inventing new names on the fly. Not nice - but for a CP/M-clone, it's
|
|
> quite impressive.
|
|
|
|
Note I said *really* use. :-) Ending up with filenames like
|
|
EMAC~BIN.T~Z, or worse, just isn't my idea of really working...
|
|
|
|
I agree it's quite impressive that it can be done at all. Saying that
|
|
was what triggered this entire thread...
|
|
|
|
> > So when is the ext2fs for DOS going to be ready? :-]
|
|
>
|
|
> Hmm. Now, how large would that be? Could we do something useful with it
|
|
> without using a DOS-extender? :-)
|
|
|
|
Doubtful...
|
|
|
|
--
|
|
- David A. Holland | "The right to be heard does not automatically
|
|
dholland@husc.harvard.edu | include the right to be taken seriously."
|
|
- - - - - - - - - -
|
|
This message shall NOT be quoted or copied out of the electronic medium
|
|
in which it originated without explicit permission from the author.
|
|
|
|
------------------------------
|
|
|
|
From: jfh@rpp386 (John F. Haugh II)
|
|
Subject: Re: YP or NIS for linux?
|
|
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
|
|
Date: Tue, 15 Mar 1994 04:09:17 GMT
|
|
|
|
In article <2lv16t$7nk@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes:
|
|
>And what do you do if the DBM databases are corrupt and causes
|
|
>/bin/login to core dump? (Atleast one version of GDBM had the
|
|
>nasty habit of calling abort() if it detected something wrong
|
|
>with its database files).
|
|
>
|
|
>One can always find situations where there will be problems
|
|
>and no way of doing things (DBM, YP, NIS+, DNS/Hesiod) will
|
|
>ever be perfect.
|
|
|
|
Problems such as this are readily solvable in the permanent
|
|
sense. When a YP server goes down, you can't reboot it and
|
|
expect it to stay up forever.
|
|
|
|
I don't use YP on any system were availablity is an issue. I
|
|
don't even rely on AFS or NFS on critical systems. There is
|
|
no substitute for having the data right here, right now.
|
|
--
|
|
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: YP or NIS for linux?
|
|
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
|
|
Date: Tue, 15 Mar 1994 04:12:45 GMT
|
|
|
|
In article <2lvm8p$2hu@finnegan.iol.ie> barryf@iol.ie (Barry Flanagan) writes:
|
|
>jfh@rpp386 (John F. Haugh II) wrote:
|
|
>>I have spoken with people who use DBM files to support
|
|
>>/etc/passwd files with upward of 30,000 users. I'm
|
|
>>not aware of any scalability problems with DBM files.
|
|
>>I am aware of problems pushing YP maps that are that
|
|
>>size.
|
|
>>--
|
|
>
|
|
>I would really appreciate some pointers to more information on
|
|
>this. It appears that NIS (at least on SCO) becomes very flakey
|
|
>with upwards of 100 users, which seems to me to defeat the
|
|
>purpose of NIS.
|
|
>
|
|
>I need to share passwd/shadow files between different types of
|
|
>Unix (currently SCO, Solaris and Linux) and need to be able to
|
|
>add many users.
|
|
|
|
I don't know of specific problems, but the most common is
|
|
that some systems don't know how to incrementally update a
|
|
map. One of the big advantages that Shadow has had over the
|
|
commercial vendors is that chfn, chsh and passwd -- all the
|
|
heaviest I&A file updates -- have long supported incremental
|
|
file updates for the DBM files.
|
|
|
|
The problem, as it relates to NIS, is that the maps either
|
|
take forever to recreate, copy, or whatever, or they stay out
|
|
of date for long periods of time.
|
|
|
|
As for SCO, toss it out and get something real. SCO UNIX isn't
|
|
UNIX.
|
|
--
|
|
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: A truely non-debugging Kernel?
|
|
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
|
|
Date: Tue, 15 Mar 1994 04:14:50 GMT
|
|
|
|
In article <1994Mar13.205037.24215@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
|
|
>Well what do you do then if the kernel suddenly goes bonkers one day,
|
|
>and clobbers you /usr partition or something awful like that?!
|
|
>Commerical un*xes have sanity checks, etc, why shouldn't Linux? Plus, if
|
|
>you have a very intermittent problem, the debug stuff might make it
|
|
>possible to find out what it is, else you'll never know. You'd have to
|
|
>recompile with debugging after the fact and wait for it to happen again.
|
|
>That might be an uncomfortable wait for those with mission-critical or
|
|
>security related problems.
|
|
|
|
When I was a developer on AIX v3.1 a few years back, we reached a point
|
|
where they turned off a lot of the macros controller those sanity checks.
|
|
|
|
The idea isn't that you install "new and buggy" kernel today with the
|
|
#ifdef's all turned off. The idea is that you prove to yourself that
|
|
"new and buggy" is really "old and reliable" THEN you turn off the
|
|
#ifdef's.
|
|
--
|
|
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: YP or NIS for linux?
|
|
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
|
|
Date: Tue, 15 Mar 1994 04:25:54 GMT
|
|
|
|
In article <2lv0tp$7m3@celsius.ifm.liu.se> peter@ifm.liu.se (Peter Eriksson) writes:
|
|
>In NYS I've made one extension and that is to use /etc/passwd as a
|
|
>source for Shadow information if the file /etc/shadow doesn't exist
|
|
>so one can have _one_ /bin/login binary that works with or without
|
|
>the file "/etc/shadow".
|
|
|
|
Peter -- KNOCK, KNOCK -- Peter, you can do that with Shadow RIGHT
|
|
NOW. TODAY. You can even do it with SVR4's /bin/login. TODAY.
|
|
|
|
You've made up an extension and if that is the justification, there
|
|
is no reason for it. I'm telling you -- and I've been doing this
|
|
particular collection of bizarre software for several years longer
|
|
than you so you really should pay attention here -- what you are
|
|
doing is just a bad idea. There is value in knowing if there is an
|
|
/etc/shadow entry, even if the entry came from /etc/shadow on some
|
|
other machine. There is value in being able to use getspnam() on
|
|
every machine that supports /etc/shadow, even if that /etc/shadow
|
|
can be on some other machine. Your change REMOVES that value.
|
|
|
|
>Even if I hadn't made that extension then one still would have to
|
|
>find out from which source the data comes if one wants to modify it
|
|
>and send it back. So what's the big deal with my addition to the
|
|
>functionality?
|
|
|
|
I've not checked, but my guess is that you provide no means for
|
|
determining if the YP entry came from over the wire or locally.
|
|
Am I correct?
|
|
|
|
>NDBM has a very big limitation. Namely the 4096 bytes / key-value pair
|
|
>limit. One thing I've tried to avoid in NYS is stupid builtin limitations
|
|
>like that.
|
|
|
|
As much as I hate to say this, Shadow using NDBM does not have the
|
|
4096 byte key/value pair limitation for /etc/group (which is about the
|
|
only place anyone runs into it).
|
|
--
|
|
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.
|
|
|
|
------------------------------
|
|
|
|
Date: 14 Mar 1994 23:54:00 +0100
|
|
From: kai@khms.westfalen.de (Kai Henningsen)
|
|
Subject: Re: Amiga FileSystem, Anyone?
|
|
|
|
dholland@husc7.harvard.edu wrote on 13.03.94 in <DHOLLAND.94Mar13041044@husc7.harvard.edu>:
|
|
|
|
> True. But it's not real workable as an easy general solution -
|
|
|
|
That's because
|
|
1. DOS is single-tasking single-address-space
|
|
2. 640K is not a lot of memory for today's programs.
|
|
|
|
There *is* no simple solution to these problems.
|
|
|
|
> I mean that Microsoft won't support it. Microsoft has been known to
|
|
> intentionally change these things to try to break somebody else's
|
|
> program. Maybe the existence of Novell DOS will stop them now, maybe
|
|
> not; who knows?
|
|
|
|
They have even done this with normal DOS. That's Microsoft to you. :-(
|
|
|
|
> > 3. *Of course* you are limited to 8+3 - that's DOS's *concept* of a
|
|
> > filesystem.
|
|
>
|
|
> Well, that's broken, and makes it impossible for DOS to really use
|
|
> most other filesystems. :-)
|
|
|
|
Hmm. Now, why have I seen DOS "use" lots of file systems that weren't 8+3?
|
|
Of course, using various work-arounds, like only seeing some files, or
|
|
inventing new names on the fly. Not nice - but for a CP/M-clone, it's
|
|
quite impressive.
|
|
|
|
> > 4. Various programs are either not suitable for working with anything but
|
|
> > a FAT file system, because they know too much about it, or else have
|
|
> > stupid bugs. It's the same with, say, Unix & NFS.
|
|
>
|
|
> True...
|
|
>
|
|
> > NETX is simply stone-age code.
|
|
>
|
|
|
|
> That's obviously the case. It seems the state of the art has managed
|
|
> to improve a bit since I last really paid attention to the DOS world
|
|
> (which wasn't all that long ago, before everybody jumps down my throat.)
|
|
|
|
A bit, yes.
|
|
|
|
> Evidently. Isn't it amazing how much easier it when people explain
|
|
> instead of just saying "you're an idiot"?
|
|
|
|
Definitely.
|
|
|
|
> So when is the ext2fs for DOS going to be ready? :-]
|
|
|
|
Hmm. Now, how large would that be? Could we do something useful with it
|
|
without using a DOS-extender? :-)
|
|
|
|
|
|
Kai
|
|
--
|
|
Internet: kh@ms.maus.de, kai@khms.westfalen.de
|
|
Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai}
|
|
## CrossPoint v2.93 ##
|
|
|
|
------------------------------
|
|
|
|
From: henryc@reality.UUCP (Christian Henry)
|
|
Subject: Re: DIP: tty: getc: I/O error
|
|
Reply-To: henryc%reality%ionews@io.org
|
|
Date: Mon, 14 Mar 1994 14:59:50 GMT
|
|
|
|
In article <1994Mar13.140017.293@ijssel.hacktic.nl>,
|
|
Arnoud Martens <arnoudm@ijssel.hacktic.nl> wrote:
|
|
|
|
>> 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).
|
|
|
|
It's too bad that the man pages for even some of the most up to date
|
|
versions of dip do _not_ describe what the `-k' option does.
|
|
|
|
--
|
|
| Christian Henry | e-mail: henryc%reality%ionews@io.org (preferred) |
|
|
| | or: henryc@io.org (if above address bounces) |
|
|
| ``Blind - Product of pride. F*cker, you don't speak for me...'' - CoC |
|
|
|
|
------------------------------
|
|
|
|
From: ddj+@cs.cmu.edu (Doug DeJulio)
|
|
Subject: Re: Andrew 6.1 for Linux: who did it?
|
|
Date: Wed, 16 Mar 1994 04:33:36 GMT
|
|
|
|
In article <1994Mar15.195914.326@hisplace.rhein-main.de>,
|
|
Marko Schuetz <marko@hisplace.rhein-main.de> wrote:
|
|
>I grabbed a copy of the Andrew Toolkit for Linux version 6.1 and I must say
|
|
>that this port definitely causes more problems than it solves.
|
|
>Most of all it seems incomplete.
|
|
>For example the .overview files are missing, templates are missing and
|
|
>much much more.
|
|
>Yet it's amazing to see what already does run, so I was wondering
|
|
>if anyone has solved all these problems and tailored a running Andrew >= 6.1.
|
|
|
|
It's all there, nothing is missing. The thing is, there are *two*
|
|
files you need to install. One of them is labeled as the "programmer
|
|
stuff", libraries and include files and the like. That's where the
|
|
overviews, templates, and so on are kept. You have to install *all*
|
|
of it in order to get *any* of it to work properly.
|
|
|
|
I'm just waiting for X11R6, so I can get the ATK 6.1 source and
|
|
compile it up myself.
|
|
|
|
--
|
|
Doug DeJulio
|
|
ddj+@cmu.edu
|
|
|
|
------------------------------
|
|
|
|
From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
|
|
Subject: Re: TTY overruns cost money.
|
|
Date: 15 Mar 1994 06:07:36 GMT
|
|
|
|
On Tue, 15 Mar 1994 02:56:03 GMT, Nemosoft Unv. wrote:
|
|
|
|
> Anyway, my questions still stand: why is now all this attention payed to
|
|
> some vague bit that tells me something is overrunning, while I obviously
|
|
> loose no data, and why am I even bothered by them at 2400 baud ? That's
|
|
> ridiculous. I've never seen any MS-DOS comm-program bitch about overruns,
|
|
> not even at extreme high speeds like 115200 baud on an 8088 XT. And then I
|
|
> didn't loose a single byte !
|
|
|
|
Well, the questions is, how do you know? I'd be surprised if you'd never
|
|
lost a character at 115Kbaud.
|
|
|
|
And another thing, DOS is not linux. DOS is a single task hogging the
|
|
entire machine. You don't have disk access, sound playing and serial comms
|
|
all at the same time (at least not during normal MSDOS style operations).
|
|
You don't get a situation where the computer is doing something else when
|
|
the serial port decides now is a good time for the computer to receive some
|
|
data.
|
|
|
|
> Why is it that the Linux serial drivers suddenly seem to be so broken down,
|
|
> in comparison with this ? Maybe we should turn back to some good-ol'
|
|
> assembler code ?
|
|
|
|
Actually, they're not suddenly broken down. A decision was made to report
|
|
the input overrun errors. They were happening before. You just weren't
|
|
being told about it!
|
|
|
|
--
|
|
[==================================================================]
|
|
[ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ]
|
|
[ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ]
|
|
[ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ]
|
|
[==================================================================]
|
|
|
|
------------------------------
|
|
|
|
From: mparanj@eis.calstate.edu (Milind Paranjpe)
|
|
Subject: Fooling with the timer interrupt
|
|
Date: 14 Mar 1994 22:35:08 -0800
|
|
|
|
Hello Linuxers,
|
|
|
|
I've been thinking of writing a Linux driver for an A/D card.
|
|
The card doesn't have any kind of buffer or clocking mechanism
|
|
to do continuous conversions. This means that I'll have to
|
|
speed up the timer. Can someone please comment on whether
|
|
this is recommended/possible? Under dos it was easy--just
|
|
write a value smaller than 0xffff to io address 0x40, and
|
|
call the original timer routine once in a while. I took a
|
|
brief look at the kernel source yesterday, and noticed that
|
|
the timer interrupt rate is 100Hz by default (at least in
|
|
0.99.15d). I wouldn't know what's involved in making this
|
|
around 4000Hz.
|
|
|
|
Any comments much appreciated.
|
|
|
|
Milind
|
|
|
|
------------------------------
|
|
|
|
From: jhonan@lsupoz.apana.org.au (Jamie Honan)
|
|
Subject: Fonts, keyboards, mice - a proposal
|
|
Date: 15 Mar 1994 16:33:58 +1000
|
|
|
|
This article contains a proposal as to how emulation, national keyboard
|
|
and font support might be taken out of the kernal and placed in a
|
|
user process. This proposal also has the advantage that it lends
|
|
itself to implementation of mouse and svga server processes.
|
|
|
|
Please note my preferred email address at the end.
|
|
|
|
Preamble: The line of thought...
|
|
===============================
|
|
|
|
Recently, I was looking at the 'selection' package, with a view to using
|
|
the mouse code.
|
|
|
|
My idea was to integrate character mode mouse handling with the dialog
|
|
package.
|
|
|
|
The initial problem was that there is only one /dev/mouse device, and
|
|
'selection' must 'fight' over reading this device with any other program
|
|
that wants to use the mouse.
|
|
|
|
Contention with, say, X windows, is achieved by 'selection' backing off
|
|
and stopping reading the mouse device when the current virtual console
|
|
is in graphics mode.
|
|
|
|
This contention could be further developed, by changing selection so
|
|
that it also backed off if a certain file existed (e.g.
|
|
/USG/local/etc/STOPSELECTION)
|
|
|
|
How would multiple copies of such 'mouse reading programs' cooperate?
|
|
|
|
They could detect when virtual consoles switched, and not read the mouse
|
|
device whilst another virtual console had control.
|
|
|
|
Detecting when virtual consoles switch could be problematical. One way
|
|
is to use signals. The virtual console driver in Linux allows one to
|
|
nominate a single process id which will receive specific signals on
|
|
switching out of / into a virtual console.
|
|
|
|
An example of how this is done can be seen in the svga library package.
|
|
|
|
The problem with this approach is that it would require a library
|
|
routine (this is how one would like a mouse handler to be done) that
|
|
reserves use of two signals, takes control and disables a process when
|
|
the virtual console is switched. This is precisely what happens in the
|
|
svga library, and such mouse library code would obviously conflict.
|
|
|
|
Another way of detecting virtual console switch is to extend the ioctl
|
|
call VT_WAITACTIVE. This takes as an argument the virtual console number
|
|
that we are waiting to become active.
|
|
|
|
If this were to be extended, such that the argument could also be zero,
|
|
meaning 'release the ioctl when any new virtual console was switched
|
|
to', this could be more useful.
|
|
|
|
Being an ioctl, this would require an entire process waiting. The best
|
|
thing would be a select call on some magic fd, that released when any
|
|
virtual console switched.
|
|
|
|
Further thinking about mice lead to this thought: What about doing mouse
|
|
tracking with a graphics type mouse cursor in text mode? This is done in
|
|
such packages as Norton's Utilities in DOS.
|
|
|
|
This is done by redefining the fonts of four rarely used characters, and
|
|
re-mapping them with a graphics cursor overlaid. There is some example
|
|
code from Dave Kirsch, for the DOS world.
|
|
|
|
This requires fiddling with the RAM based fonts in VGA/EGA. Since one
|
|
only wants to change four characters, there are two options for doing
|
|
this:
|
|
|
|
1. Change io permission level (requires setuid root) to re-program VGA
|
|
registers and write the font RAM.
|
|
or
|
|
2. Put support in the kernel to allow this with either an ioctl or
|
|
special VT type escape sequence.
|
|
|
|
Option two is what the 'national' package does to load national fonts.
|
|
This consists of kernel patches to allow an entire font to be loaded.
|
|
|
|
There are some limitations with this. When the console is switched from
|
|
character mode to graphics mode (or is it the other way round?), the
|
|
default character set is reloaded by the VGA controller. This is a
|
|
current problem for 'national'.
|
|
|
|
All this is turning into a classic 'do it in the kernel' versus 'do it
|
|
by user process' clash. Should the kernel keep a copy of the current
|
|
font? Should the kernel do the mouse tracking?
|
|
|
|
Objectives: What would be nice...
|
|
=================================
|
|
|
|
Then there are other things that one would like to do. It would be nice
|
|
to improve / modify / replace the VT100 emulation in the kernel with
|
|
another type, without modifying the kernel.
|
|
|
|
It would be nice to have a mouse 'server' - only one place where the
|
|
type of mouse was defined, and everybody else read a standard sort of
|
|
mouse code. In addition, the mouse server could keep the number of
|
|
'mickeys' defined for the current virtual console, any boundaries on how
|
|
far the mouse could move, and only feed those processes that were
|
|
interested for a virtual console. The mouse server would also handle visual
|
|
feedback.
|
|
|
|
It would be nice to have a super vga server program, only one program
|
|
that was setuid root. Other programs could use it to do graphics.
|
|
|
|
It would be nice to implement a mouse emulator with keyboard keystrokes
|
|
(c.f. pcvct - a virtual console package recently posted to comp.sources
|
|
for BSD)
|
|
|
|
And it would be nice to do all this without modifying the kernel. In
|
|
fact if the kernel could be made smaller, all the better.
|
|
|
|
Proposal:
|
|
==========
|
|
|
|
Here is a proposal that might allow us to do all of the above, but
|
|
requires changing the kernel.
|
|
|
|
The proposal is, that under /proc there is a subdirectory /proc/vc<n>,
|
|
where n is the virtual console number.
|
|
|
|
Under this directory, there is kbd and screen. When either of these is
|
|
opened for read access, they return packets of information for the
|
|
relevant virtual console.
|
|
|
|
/proc/vc<n>/kbd would return information about key presses, ioctl calls,
|
|
and other relevant raw information. This would be fairly undigested.
|
|
/proc/vc<n>/kbd, when written to, would pass information on up to the
|
|
relevant tty associated with the virtual console.
|
|
|
|
In this way, a process could handle keyboard emulation. In addition, it
|
|
could handle national character set mapping. All this would be done
|
|
without the involvement of the kernel. This process could also do
|
|
keyboard mouse emulation.
|
|
|
|
/proc/vc<n>/screen, when read, would return packets of information about
|
|
user writes, ioctls, etc. It would also return information about virtual
|
|
console switches, mode changes ....
|
|
|
|
In this way, the process reading /proc/vc<n>/screen would also control
|
|
the font displayed.
|
|
|
|
The process reading /proc/vc<n>/screen would write directly to the vga
|
|
ram and control the vga registers.
|
|
|
|
Some refinements to the above ideas include a /proc/vc directory. If
|
|
there is no /proc/vc<n>/kbd opened for read for a particular virtual
|
|
console, and /proc/vc/kbd was, then the packets would go there. If
|
|
neither was opened, then the keystrokes would be mapped rather simply
|
|
and crudely, and passed to the appropriate tty.
|
|
|
|
Similarly, if there was no /proc/vc<n>/screen opened for read, and
|
|
/proc/vc/screen was, then the packets would go there. If neither was
|
|
opened, then the screen would be written to in a crude way.
|
|
|
|
With this, the entire national font, national keyboard, specialised
|
|
keyboards, special VGA characteristics could be taken OUT of the kernel.
|
|
In addition, you could take the VT100 emulation out! You could place
|
|
the VT100 emulation in a process that was controlling /proc/vc. Then if
|
|
you wanted a VT220 emulation on VC 2, you could place that process on
|
|
/proc/vc2. If you wanted an IBM-PC emulation, this could go in it's own
|
|
process.
|
|
|
|
Another refinement is that the select call should be supported, as well
|
|
as open NONBLOCK. In addition, like fifos, the writes should be atomic
|
|
if less than the buffer size.
|
|
|
|
One other thing which would be useful for a mouse server, would be
|
|
/proc/vc/current. When read, this would always return the current vc,
|
|
and perhaps mode information. A select on this would only be released
|
|
when there was a status change, e.g. mode, or virtual console switch.
|
|
|
|
Objections to this scheme.
|
|
===========================
|
|
|
|
Obviously this requires extra process switching. The good thing is that
|
|
this is being done on slow devices - keyboards, mice, screen writes (it
|
|
would not be done on individual character screen writes, these would be
|
|
buffered) - so this doesn't matter that much.
|
|
|
|
Obviously this puts a fair degree of burden on a user level process.
|
|
The kernel could conceivably be operating quite correctly, whilst the
|
|
emulation has crashed or locked up. The user would be unable to do
|
|
anything.
|
|
|
|
Just some thoughts....
|
|
|
|
Jamie (please note for email jhonan@jolt.mpx.com.au )
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: biegler@aristotle.cs.uregina.ca (Mark Biegler)
|
|
Subject: [Q] Adaptec 2842 SCSI driver yet?
|
|
Date: Tue, 15 Mar 1994 05:33:50 GMT
|
|
|
|
Hello,
|
|
|
|
Is the Adaptec 2842 SCSI driver available yet? The Hardware-HOWTO
|
|
doesn't mention it, and the SCSI-HOWTO states that's it's being worked
|
|
on, but both are a bit out of date. As well, the Slackware SCSI
|
|
bootdisk doesn't seem to have it as an option.
|
|
|
|
We will be making a few computer acquisitions and would like to use
|
|
this adaptor with Linux, but I need information ASAP. I'd hate to
|
|
have to buy something else if it's only a month away.
|
|
|
|
Thanks muchly,
|
|
|
|
Mark Biegler
|
|
|
|
=====
|
|
Mark Biegler (VE5MPB) biegler@cs.uregina.ca
|
|
Department of Computer Science W: (306) 585-4110
|
|
University of Regina H: (306) 522-1770
|
|
Regina, Saskatchewan Canada S4S 0A2 Office: CW 307.12
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|