725 lines
30 KiB
Plaintext
725 lines
30 KiB
Plaintext
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, 26 Feb 94 10:13:04 EST
|
|
Subject: Linux-Development Digest #500
|
|
|
|
Linux-Development Digest #500, Volume #1 Sat, 26 Feb 94 10:13:04 EST
|
|
|
|
Contents:
|
|
Re: ipcs utility, /proc page allocation (Frank Lofaro)
|
|
Re: PLEASE use the GPL -- NOT (Matt Birkholz)
|
|
Re: Specialix driver (Frank Lofaro)
|
|
Floppy driver is hosed! (Frank Lofaro)
|
|
Re: Specialix driver (Charles Hedrick)
|
|
Re: floppy: drive 0 is write protected (Jorge Cwik)
|
|
Re: accessing BIOS (David Holland)
|
|
Re: Context switch for pthreads (Matthew Donadio)
|
|
Re: undefined symbols in modules (John Paul Morrison)
|
|
Re: Context switch for pthreads (Christopher Andrew Smith)
|
|
undefined symbols in modules (Erik Troan)
|
|
Re: Driver for dumb digiboard? (Rob Janssen)
|
|
Re: floppy: drive 0 is write protected ad nauseum (Rob Janssen)
|
|
Re: undefined symbols in modules (Rob Janssen)
|
|
Re: Specialix driver (Craig Milo Rogers)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: ftlofaro@unlv.edu (Frank Lofaro)
|
|
Subject: Re: ipcs utility, /proc page allocation
|
|
Date: Fri, 25 Feb 94 05:27:11 GMT
|
|
|
|
In article <2kimjb$obb@openwx.networx.com> bonn@badger.networx.com (David Bonn) writes:
|
|
>A project I've been working on needs the ipcs and ipcrm programs. It is
|
|
>simple to write ipcrm using existing msgctl(), semctl(), and shmctl() calls,
|
|
>but ipcs needs to peek in kernel space.
|
|
>
|
|
>No problem, just write a /proc/ipc entry that dumps all the relevant stuff
|
|
>out. Three reboots later I had this straight. However, my approach has a
|
|
>huge flaw: since we only allocate one page for the /proc/ipc info in
|
|
>array.c, something with a lot of output (e.g. 128 shared memory segments)
|
|
>could overrun that page and stomp whatever is beyond it. This would be
|
|
>very bad.
|
|
>
|
|
>I see a couple of ways to deal with this:
|
|
>
|
|
> (1) Allocate <n> contiguous pages, where <n> * pagesize() is guaranteed
|
|
> to be large enough to hold the maximum amount of output. This may or
|
|
> may not work, I haven't looked hard enough.
|
|
>
|
|
> (2) Check for overrun and fail if we overrun. This is likely to be
|
|
> tedious to detect. I'd rather just make sure it won't happen.
|
|
>
|
|
> (3) Make /proc/ipc a separate subdirectory, with file entries for each
|
|
> ipc object. This is probably closest to the 'spirit' of /proc.
|
|
>
|
|
>What I'd like to know is if I'm missing some important alternatives; and if
|
|
>someone else has already solved this problem.
|
|
>
|
|
>--
|
|
>
|
|
> David Bonn "it's an attitude"
|
|
> bonn@networx.com
|
|
|
|
Or how about what /proc/kcore uses:
|
|
|
|
(4) Write something like a memory device driver (/proc/kcore was
|
|
/dev/core), and do not use the page given, but kmalloc your own space,
|
|
or whatever. Check read_core in linux/fs/proc/array.c for how it is
|
|
done. All of the /proc/files should be done this way, the
|
|
auto-allocation of one page system is a bit of a kludge.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: birkholz@ai.mit.edu (Matt Birkholz)
|
|
Subject: Re: PLEASE use the GPL -- NOT
|
|
Date: 26 Feb 94 04:15:50
|
|
|
|
From: kem@prl.ufl.edu (Kelly Murray)
|
|
Newsgroups: comp.os.linux.development
|
|
Date: 23 Feb 1994 23:52:20 GMT
|
|
References: <NELSON.94Feb22204008@crynwr.crynwr.com> <NELSON.94Feb23113520@crynwr.crynwr.com>
|
|
|
|
[...]
|
|
Maybe after everyone else has debugged it, extended it, passed it around,
|
|
wrote scripts for it, learned to use it, wrote HOW-TO's and documention for it,
|
|
the authors might suddenly claim their original work was really very
|
|
valuable, and they should get compensated for it now.
|
|
|
|
Duh. Then I keep my well-debugged version under the license upon which we
|
|
already agreed and ignore them. I even keep getting new versions from the
|
|
net as debugging and extending continue. They can't stop me; they can't
|
|
change the conditions of the agreement after the fact. Even if they could,
|
|
it is tantamount to breach of contract.
|
|
|
|
Considering how little the GPL constrains your work, I'm surprised to see
|
|
you grasping at straws.
|
|
|
|
If you don't agree with the goals of the GPL, don't use it. Is somebody
|
|
holding a gun to your head?
|
|
|
|
Matt Birkholz
|
|
birkholz@martigny.ai.mit.edu
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: gnu.misc.discuss
|
|
From: ftlofaro@unlv.edu (Frank Lofaro)
|
|
Subject: Re: Specialix driver
|
|
Date: Fri, 25 Feb 94 06:24:04 GMT
|
|
|
|
In article <1994Feb25.010232.4865@rpp386> jfh@rpp386.cactus.org (John F. Haugh II) writes:
|
|
>In article <140887@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Robert Sanders) writes:
|
|
>>I'm surprised that with the recent silliness over the Shadow suite that
|
|
>>you haven't heard some of the more recent interpretations. RMS and
|
|
>>others maintain that any program written to use an interface which
|
|
>>is solely available under the GPL is to be considered a derived work.
|
|
>>For example, if the only C library were glibc, and it was under the GPL
|
|
>>and not the GLPL, until someone wrote a non-GPL'ed libc, any code that
|
|
>>used printf() would be a derived work. For more on this, ask about
|
|
>>the gmp debacle on gnu.misc.discuss.
|
|
>
|
|
>It doesn't matter what announcements RMS makes. There is no legal way
|
|
>for you to claim that something which contains no derived code is a
|
|
>derived work. Linux is not distributed with any form of non-disclosure
|
|
>so all of the interfaces are public. And I can code to a public
|
|
>interface any time I want.
|
|
>
|
|
>>I would posit that the Linux kernel is the only available implementation
|
|
>>of the Linux kernel interface. The Linux kernel is GPL'ed, therefore
|
|
>>any driver written to interface with the kernel is GPL'ed. Russ's
|
|
>>assertion is correct in the eyes of the FSF.
|
|
>
|
|
>A public interface is never subject to license restrictions. IBM has
|
|
>tried this position and lost. Consider the System/370 plug compatible
|
|
>computer systems. IBM tried to control the interface, and lost. I
|
|
>suspect that the FSF would lose as well. If they didn't lose, I'd suggest
|
|
>any company being affected file a restraint of trade suit.
|
|
>
|
|
>>Of course, you're not even arguing that far. You say that even .o
|
|
>>that are only intended to link into a GPL'ed program need not be GPL'ed.
|
|
>
|
|
>Correct. I can write anything I like to any public interface I like. If
|
|
>I don't want to distribute that thing under the terms of the GPL all I
|
|
>have to do is avoid contaminating my code with something which is under
|
|
>the terms of the GPL. And public interfaces aren't subject to licensing
|
|
>restrictions.
|
|
>--
|
|
>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.
|
|
|
|
Well said. I REALLY DON'T want to see the FSF using the overly broad
|
|
interpretation of "derived work". It could come back to haunt them by setting
|
|
a precedent; one day in fact impeding free software that interfaces to or runs
|
|
on or with commerical software. Something is only a "derived work" if it is a
|
|
work derived from the program it is supposedly derived from. Being made to
|
|
_work with_ does not mean _derived from_.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: ftlofaro@unlv.edu (Frank Lofaro)
|
|
Subject: Floppy driver is hosed!
|
|
Date: Fri, 25 Feb 94 05:59:03 GMT
|
|
|
|
The floppy driver is hosed.
|
|
|
|
In the process of implementing raw devices on my system (they
|
|
still need a tad of work done), I noticed a really OBNOXIOUS problem
|
|
in the floppy driver. It only works with a blocksize of 1024! (i.e 2
|
|
sectors). If I use more, it only reads/writes 2 sectors out of 8 (1K
|
|
out of 4K), leaving whatever junk was there in the remaining 3k of the
|
|
buffer or the disk. If I use 512 bytes (1 sector), it seems to work
|
|
for all sectors but the last on a track, but things still may be
|
|
getting trashed.
|
|
Here is the kicker! If I try to write the last sector on a
|
|
track, if I am LUCKY all I get is an error saying the FDC reported
|
|
error status 0x44 0x80 (cylinder overrun, i.e. sector number too
|
|
high). If I am not lucky (i.e. 90% of the time), the system will
|
|
immediately REBOOT! (no panic, kernel messages or nothing, just as if
|
|
I hit the reset button).
|
|
I had to use a blocksize of 1024 to get it to work. It
|
|
indicates the floppy driver needs work, especially if the kernel is to
|
|
support multiple blocksizes well, as is planned.
|
|
|
|
P.S. The floppy problem is why swapon /dev/fd0 does not work:
|
|
|
|
121: whitney: 21:54:02: /usr/users/ftlofaro: # swapon /dev/fd0
|
|
Unable to find swap-space signature
|
|
swapon: /dev/fd0: Invalid argument
|
|
122: whitney: 21:54:13: /usr/users/ftlofaro: # swapon /dev/fd0H1440
|
|
Unable to find swap-space signature
|
|
swapon: /dev/fd0H1440: Invalid argument
|
|
|
|
Swapping to a device tries to do 4K I/O, but only 1K is
|
|
transferred; the rest of the buffer or the disk area being accessed is
|
|
left uninitialized, thus containing whatever junk was there before,
|
|
Thus swapping can not find the signature (and if it could, things
|
|
would get VERY hosed when swapping actually occured).
|
|
|
|
There is a realted thread about the IN2000 SCSI adapter code,
|
|
which hoses up swapping, again due to a blocksize limitation.
|
|
|
|
P.P.S. Swapping to a floppy could be useful under some circumstances.
|
|
Like trying to install to a 4M machine using for example UMSDOS
|
|
filesystems. Systems with 4M need to be able to swap to install, and
|
|
you need to have an fs (thus need to have already installed - chicken
|
|
and egg problem) before you can swap to a file, and if you don't want
|
|
to mess with partitions, you could swap to the b: drive instead. A bit
|
|
slow but probably tolerable (Heck I swapped to a file on an ext2
|
|
floppy as a test - that works, since it is a normal 1K fs access) and
|
|
it is slow, but I can deal with it.
|
|
|
|
|
|
------------------------------
|
|
|
|
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
|
|
Subject: Re: Specialix driver
|
|
Date: 26 Feb 94 02:46:13 GMT
|
|
|
|
dholland@husc7.harvard.edu (David Holland) writes:
|
|
|
|
>All right. The Linux kernel is the only available implementation that
|
|
>will run Linux binaries. Therefore Linux binaries have been created to
|
|
>interface with the Linux kernel. The Linux kernel is GPL'd. Therefore,
|
|
>everything which has ever been compiled to run under Linux is
|
|
>automatically GPL'd.
|
|
|
|
Even if this weren't an absurd reading of the GPL, the COPYING file
|
|
distributed with the kernel explicitly says that no constraints
|
|
are placed on applications that simply use system calls.
|
|
|
|
------------------------------
|
|
|
|
From: jorge@laser.satlink.net (Jorge Cwik)
|
|
Subject: Re: floppy: drive 0 is write protected
|
|
Date: Fri, 25 Feb 94 19:05:11 -0400
|
|
|
|
niemidc@oasis.gtegsc.com (David C. Niemi) writes:
|
|
|
|
> If anyone knows how to detect either floppy changes (without repeated
|
|
> polling of the drive) or write protected floppies (without actually
|
|
> writing to the disk), please let me know. I know there are hardware
|
|
> signals from the drive that would remedy both of these problems; but
|
|
> as far as I can tell these are not directly accessible via the FDC.
|
|
|
|
The FDC "Sense Drive Status" command (0x04), returns the WP signal
|
|
among others things, and it is a totally passive command.
|
|
|
|
The "Change line" signal is available in the "Digital Input Register"
|
|
($3F7/$377). The FDC does generates an interrupt when the disk is
|
|
changed, actually a couple, one when removing a disk and a second one
|
|
when inserting it.
|
|
|
|
Jorge
|
|
|
|
|
|
------------------------------
|
|
|
|
Subject: Re: accessing BIOS
|
|
From: dholland@husc7.harvard.edu (David Holland)
|
|
Date: 26 Feb 94 02:00:10
|
|
|
|
|
|
rob@pe1chl.ampr.org's message of Thu, 24 Feb 1994 22:38:33 GMT said:
|
|
|
|
> You should certainly look at Linux for protected mode programming.
|
|
> However, Linux does not switch back to real mode by itself.
|
|
> (it *is* possible to use V86 mode in a task running under Linux,
|
|
> the DOS emulator uses it)
|
|
|
|
And this is a good reason to be able to have microkernel-style device
|
|
drivers. You can write one that runs in V86 mode and uses the BIOS to
|
|
talk to weird hardware.
|
|
|
|
--
|
|
- David A. Holland | Nobody ever went broke underestimating
|
|
dholland@husc.harvard.edu | the intelligence of the American public.
|
|
|
|
------------------------------
|
|
|
|
From: donadio@mxd120.rh.psu.edu (Matthew Donadio)
|
|
Subject: Re: Context switch for pthreads
|
|
Date: 25 Feb 1994 22:50:19 GMT
|
|
|
|
Christopher Andrew Smith (z1g192@rick.cs.ubc.ca) wrote:
|
|
: As one of my currrent projects, I am attempting to port a package called
|
|
: pthreads ( for preemptive threads ) to Linux. Most of the code should be
|
|
: relatively straightforward to port, since it is written in Ansi C, but
|
|
|
|
You shouldn't have to do any porting. The file
|
|
sipb.mit.edu:/pub/pthreads/pthreads-1.??.tar.gz
|
|
has a linux port the should work with pl15. I haven't had time to test
|
|
it thouroughly, but all the built in tests seemed to work.
|
|
|
|
: All threads are contained within one UNIX process which links in the
|
|
: pthreads library, so they share the same process space.
|
|
|
|
: A thread roughly corresponds to a procedure.
|
|
|
|
I like baby-processes.
|
|
|
|
From the LynxOS Real-Time Programming Seminar notes:
|
|
|
|
" Threads don't have a mother!
|
|
|
|
Or any siblings.
|
|
|
|
Or any children.
|
|
|
|
Sad, but true.
|
|
|
|
UNIX processes all have a semantic weight - each process has a parent
|
|
process, it may have sibling processes (who invariable squabble) and
|
|
can even fork() if it wants children.
|
|
|
|
Threads do not have a semantic weight associated with them. All the
|
|
threads within a process are completely equal - no matter which thread
|
|
created which thread.
|
|
|
|
True democrats!"
|
|
|
|
Does anyone know where to find man pages/docs for pthreads? The only
|
|
ones I have access to are 200 miles away right now. What would be
|
|
really nice if someone would start work on a kernel scheduler that is
|
|
pthread compatible. I would, but kernel work is not my thing...
|
|
Maybe this summer if I don't get a track bike.
|
|
|
|
--
|
|
Beaker aka Matt Donadio | Life is short, --- __ o __~o __ o
|
|
donadio@mxd120.rh.psu.edu | ride like ---- _`\<, _`\<, _`\<,
|
|
--- Penn State Cycling ---| the wind. --- ( )/( ) ( )/( ) ( )/( )
|
|
|
|
------------------------------
|
|
|
|
From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison)
|
|
Subject: Re: undefined symbols in modules
|
|
Date: Sat, 26 Feb 1994 08:50:10 GMT
|
|
|
|
In article <2klvfa$gtv@bigblue.oit.unc.edu>,
|
|
Erik Troan <ewt@sunSITE.unc.edu> wrote:
|
|
[ modules stuff ]
|
|
>Everything was going dandy until I tried to use call get_chrfops. When
|
|
>I try to load the module, I get the message "_get_chrfops undefined",
|
|
>though it appears in /usr/src/Linux/zSystem.map.
|
|
>
|
|
add _get_chrfops to kernel/ksyms.S
|
|
|
|
>Erik
|
|
|
|
|
|
--
|
|
==========================================================================
|
|
BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM --
|
|
jmorriso@bogomips.ee.ubc.ca jmorriso@rflab.ee.ubc.ca
|
|
==========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: z1g192@rick.cs.ubc.ca (Christopher Andrew Smith)
|
|
Subject: Re: Context switch for pthreads
|
|
Date: 25 Feb 1994 16:11:53 -0800
|
|
|
|
In article <2klvbb$5b9@genesis.ait.psu.edu> donadio@mxd120.rh.psu.edu (Matthew Donadio) writes:
|
|
>Christopher Andrew Smith (z1g192@rick.cs.ubc.ca) wrote:
|
|
>: As one of my currrent projects, I am attempting to port a package called
|
|
>: pthreads ( for preemptive threads ) to Linux. Most of the code should be
|
|
>: relatively straightforward to port, since it is written in Ansi C, but
|
|
>
|
|
>You shouldn't have to do any porting. The file
|
|
> sipb.mit.edu:/pub/pthreads/pthreads-1.??.tar.gz
|
|
>has a linux port the should work with pl15. I haven't had time to test
|
|
>it thouroughly, but all the built in tests seemed to work.
|
|
>
|
|
|
|
Yeah ... I've seen the package. My interest is purely academic, so I'm
|
|
attempting to port it to learn about OS's and kernels.
|
|
|
|
Actually, the pthreads package we use is different from the one
|
|
at MIT. Maybe not in functionality, but the source code is definitely
|
|
different.
|
|
The package I want to port was developed at University of British Columbia.
|
|
|
|
>: All threads are contained within one UNIX process which links in the
|
|
>: pthreads library, so they share the same process space.
|
|
>
|
|
>: A thread roughly corresponds to a procedure.
|
|
>
|
|
>I like baby-processes.
|
|
|
|
I like that term too! :-)
|
|
|
|
[stuff deleted]
|
|
>really nice if someone would start work on a kernel scheduler that is
|
|
>pthread compatible. I would, but kernel work is not my thing...
|
|
>Maybe this summer if I don't get a track bike.
|
|
>
|
|
This is what my ultimate goal is. (IE to make threads part of my Linux kernel)
|
|
This will probably take me quite a while, since I am just now learning about
|
|
operating systems (IE scheduling, memory management, process ADT's, critical
|
|
sections, etc ) and UNIX (Linux).
|
|
|
|
>--
|
|
>Beaker aka Matt Donadio | Life is short, --- __ o __~o __ o
|
|
>donadio@mxd120.rh.psu.edu | ride like ---- _`\<, _`\<, _`\<,
|
|
>--- Penn State Cycling ---| the wind. --- ( )/( ) ( )/( ) ( )/( )
|
|
|
|
-
|
|
|
|
|
|
|
|
--
|
|
========================================================================
|
|
|Christopher Smith | With a rubber duck, one's never alone. |
|
|
|aka z1g192@ugrad.cs.ubc.ca |-- "The Hitchhiker's Guide to the Galaxy"|
|
|
========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: ewt@sunSITE.unc.edu (Erik Troan)
|
|
Subject: undefined symbols in modules
|
|
Date: 25 Feb 1994 22:52:26 GMT
|
|
|
|
Since my girlfriend left me for a while this afternoon, I started to play
|
|
with module development, using modutils-0.99.15.tgz as uploaded
|
|
to sunsite.
|
|
|
|
Everything was going dandy until I tried to use call get_chrfops. When
|
|
I try to load the module, I get the message "_get_chrfops undefined",
|
|
though it appears in /usr/src/Linux/zSystem.map.
|
|
|
|
ie:
|
|
|
|
[3] insmod drv_load.o
|
|
_get_chrfops undefined
|
|
[4] grep chrfops /usr/src/linux/zSystem.map
|
|
0011e000 T _get_chrfops
|
|
|
|
I can call register_chrdev(), schedule(), access current, etc. with
|
|
no problems. I tried relinking my kernel to no avail.
|
|
|
|
Any clues?
|
|
|
|
Erik
|
|
--
|
|
========================================================================
|
|
"Could I bend yer ear fer a tick?" ewt@sunsite.unc.edu = Erik Troan
|
|
sasewt@unx.sas.com
|
|
- Strictly Ballroom
|
|
|
|
------------------------------
|
|
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: Driver for dumb digiboard?
|
|
Date: Sat, 26 Feb 1994 10:31:33 GMT
|
|
Reply-To: pe1chl@rabo.nl
|
|
|
|
In <CLrA6H.C9C@seastar.org> jjw@seastar.org (John Welch) writes:
|
|
|
|
> We are considering switching over from SCO Xenix to Linux, but
|
|
>have run into a snarl - it doesn't appear that Linux supports the old,
|
|
>dumb 8-port Digiboard that we currently use.
|
|
|
|
> Have I just missed it in serial.c? Or does anybody know where
|
|
>such a beastie might be obtained? ADVthanksANCE.
|
|
|
|
I don't know this specific board, but when it is a dumb board it should
|
|
be easy to support it by simply setting the I/O port addresses and
|
|
interrupt numbers. This can be done in serial.c, but it is more convenient
|
|
to run the program "setserial" at boottime (from /etc/rc), like this:
|
|
|
|
setserial /dev/ttyS2 port 0x220 irq 15 autoconfig
|
|
setserial /dev/ttyS3 port 0x228 irq 15 autoconfig
|
|
setserial /dev/ttyS4 port 0x3e8 irq 15 '^fourport' autoconfig
|
|
setserial /dev/ttyS5 port 0x2e8 irq 15 '^fourport' autoconfig
|
|
setserial /dev/ttyS6 port 0x3e0 irq 15 '^fourport' autoconfig
|
|
setserial /dev/ttyS7 port 0x2e0 irq 15 '^fourport' autoconfig
|
|
setserial -bg /dev/ttyS*
|
|
|
|
Note that some ports are configured as 'AST fourport' in serial.c, and
|
|
this flag must be cleared or there will be problems.
|
|
|
|
Note do developers (Linus, Ted): now that the automatic configuration
|
|
has been dropped, why don't we drop out all that specific info from the
|
|
rs_table? It is kind of inconvenient that one has to clear the 'fourport'
|
|
flag for ttys in the range ttyS4..ttyS11. It seems more logical for
|
|
me that the fourport owners would explicitly SET this flag.
|
|
I think it would be best to set all entries in the table above the first
|
|
four to "{ BASE_BAUD, 0x000, 0, 0 },", and let the setserial program setup
|
|
the values appropriate for the system...
|
|
|
|
Rob
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.help
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: floppy: drive 0 is write protected ad nauseum
|
|
Date: Sat, 26 Feb 1994 10:40:57 GMT
|
|
Reply-To: pe1chl@rabo.nl
|
|
|
|
In <2kjmq9$2au@wsdnws.cfi.waseda.ac.jp> 63912i@cfi.waseda.ac.jp ("Alexander During") writes:
|
|
|
|
>The thing is, Linux can check for disk changes. So you know when a new disk
|
|
>is put in. I would mount have mark this disk for non write cache initially.
|
|
>Then comes the first write, which thus goes straight onto the disk. If
|
|
>this works, the disk can safely be cached, which should be the next thing
|
|
>the VFS establishes.
|
|
>If the write fails, just tell the user program.
|
|
|
|
That should be possible, and a good solution I think.
|
|
Most problems with removable media will appear at the first write.
|
|
(or at the first read for some others)
|
|
|
|
>BTW, there is something that really bugs me every time under X. If I try
|
|
>to clean a disk with mdel and it happens to be write protected, mdel ends
|
|
>happily and all the 'write protected' messages go to the console, which I
|
|
>can't see (some thing with my site administrator, but sometimes we have
|
|
>problems talking about that stuff - he is not so good in reading English
|
|
>manuals and I have trouble explaining them in Japanese :-)). Same thing
|
|
>with any writes. Result: you write, everything seems OK and later you
|
|
>wonder where all your data is.
|
|
|
|
An easy way to see kernel messages in X is to run a:
|
|
tail -f /proc/kmsg
|
|
in some window. of course you need to run it as root.
|
|
(no need to tell me there are problems with this, and other methods to do it!)
|
|
|
|
>I think this is really a system design problem. As far as I can see, there
|
|
>is no way telling an application that it's cached write has failed. How
|
|
>about sending a SIGLOST if trouble with a file system is detected long
|
|
>after a write? I mean, it's not very compliant and all, but according to
|
|
>my linux/signal.h, this signal is not used yet and it would be a good
|
|
>thing to know something.
|
|
|
|
>Other thing, if I flush() a file, can't this be used to also flush the
|
|
>cache?
|
|
|
|
This is supposed to be done using fsync()
|
|
|
|
Rob
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: undefined symbols in modules
|
|
Date: Sat, 26 Feb 1994 10:55:01 GMT
|
|
Reply-To: pe1chl@rabo.nl
|
|
|
|
In <2klvfa$gtv@bigblue.oit.unc.edu> ewt@sunSITE.unc.edu (Erik Troan) writes:
|
|
|
|
>Since my girlfriend left me for a while this afternoon, I started to play
|
|
>with module development, using modutils-0.99.15.tgz as uploaded
|
|
>to sunsite.
|
|
|
|
>Everything was going dandy until I tried to use call get_chrfops. When
|
|
>I try to load the module, I get the message "_get_chrfops undefined",
|
|
>though it appears in /usr/src/Linux/zSystem.map.
|
|
|
|
>ie:
|
|
|
|
>[3] insmod drv_load.o
|
|
>_get_chrfops undefined
|
|
>[4] grep chrfops /usr/src/linux/zSystem.map
|
|
>0011e000 T _get_chrfops
|
|
|
|
>I can call register_chrdev(), schedule(), access current, etc. with
|
|
>no problems. I tried relinking my kernel to no avail.
|
|
|
|
>Any clues?
|
|
|
|
>Erik
|
|
|
|
I think you should put the symbol in kernel/ksyms.S, the list of symbols
|
|
exported to modules.
|
|
|
|
Rob
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: rogers@drax.isi.edu (Craig Milo Rogers)
|
|
Subject: Re: Specialix driver
|
|
Date: 25 Feb 1994 13:20:38 -0800
|
|
|
|
First, the CYA announcement: I am not a lawyer. The contents of
|
|
this message do not represent legal advise.
|
|
|
|
In article <1994Feb22.173853.19781@super.org> becker@super.org (Donald J. Becker) writes:
|
|
>A Linux device driver, on the other hand, is an integral and
|
|
>inseparable(1) part of the Linux kernel. By the terms of the GPL it must be
|
|
>released in source form.
|
|
|
|
I apologize for disagreeing with an important Linux device driver
|
|
writer, but this statement is too general.
|
|
|
|
First the good news, which some will consider the bad news: :-)
|
|
|
|
Organize your device driver into two sections. The "pure"
|
|
part should: 1) contain the code you want to keep secret, and 2)
|
|
should work (compile, execute) for several different operating
|
|
systems, without ifdefs of other operating-specific checks. The
|
|
other, "impure", part, must contain all global names, subroutine
|
|
calls, etc. which make up the interface for a particular operating
|
|
system. To protect yourself, you ought to have "impure" parts actually
|
|
working for more than one operating system. You might consider
|
|
distributing versions for freeBDS, netBDS, SCO, Netware, BSD386, ...
|
|
|
|
Under the terms of the GPL (version 2 assumed in this
|
|
discussion), you are free to distribute your "pure" portion in ways
|
|
that do not comply with the GPL, such as an object-only distribution.
|
|
The GPL does not apply to the "pure" code, and the GPL even has the
|
|
grace to explicitly acknowledge this.
|
|
|
|
It is also important to remember that the GPL does not prevent
|
|
you from modifying GPLed stuff into non-GPL-conformable stuff (in
|
|
source or object format), so long as you do not distribute or publish
|
|
the modified works (Section 2b).
|
|
|
|
Under the terms of the GPL (assuming that these hold in
|
|
court), the Linux-impure part of your driver *must* be distributed in
|
|
a GPL-compliant fashion. Distributing it as source code is, one
|
|
hopes, safe. Distributing it as object code might be open to
|
|
question: it might be considered incomplete without the "pure" code.
|
|
One way around this is to use the same "impure" code with several
|
|
different "pure" parts, and release one of these "pure" parts in
|
|
source form. A crippled copy of your "pure" secret code may be open
|
|
to attack, so it would be better to have a verifiably independent
|
|
non-secret "pure" part available.
|
|
|
|
Now for the bad news (some people's good news :-): It would be
|
|
inadvisable to distribute your pure secret and the and Linux-impure
|
|
portions linked together into a single object module or executable.
|
|
Doing so would violate the GPL. Your complete driver, without source
|
|
to the pure part, may not be linked as part of a publicly-distributed
|
|
kernel distribution, for example. *You* may not supply your customers
|
|
with a prelinked Linux kernel containing your partially-secret driver,
|
|
either.
|
|
|
|
>Responding to some of the other followups: 'modules', a mechanism loadable
|
|
>kernel device drivers, does not change the terms of the GPL. Both the letter
|
|
>and the intent of the GPL is to insure source-code-available distributions.
|
|
>A loadable module is designed to work integrally and inseparably with only
|
|
>the Linux kernel, and merely distributing it separately does not relieve it
|
|
>of the GPL obligations. The difference in method by which a 'modules'
|
|
>device driver is integrated with the remainder of the kernel (a run-time
|
|
>linkage vs. a kernel-compile-time linkage) is minor and irrelevant.
|
|
|
|
While I acknowledge that a "modules" mechanism doesn't change
|
|
the terms of the GPL, it may nonetheless critically change how the GPL
|
|
applies. Assume,as a strawman, that the runtime kernel module loader
|
|
can load a secret, "pure" object file as a seperate step from loading
|
|
a GPL-compliant "impure" object file. [I do not know whether the current
|
|
modules package can do this, and I apologize for not researching before
|
|
speculating.] Consider a package containing:
|
|
|
|
1) the Linux "impure" part, in object and source code,
|
|
|
|
2) your "pure" secret part, in object code only,
|
|
|
|
3) some independent (in the legal sense) "pure" part, in object
|
|
and source code.
|
|
|
|
This should, I hope, qualify as "mere aggregation" of your non-GPLed
|
|
secret with a GPLed work, as allowed by Section 2 of GPL2. [However,
|
|
as I said, I am not a lawyer, and I offer a layman's opinion, not a
|
|
legal one. There may be circumstances in which the package of three
|
|
files might be considered "whole" instead of an "aggregation".]
|
|
|
|
Such a distribution would be a lot more convenient to use than
|
|
one that requires each customer to static link their own kernel.
|
|
|
|
Thus, the introduction of loadable modules effectively
|
|
increases the potential to create and distribute non-GPL-conformant
|
|
Linux device drivers, as part of a commercial Linux distribution or in
|
|
a package delivered to a customer of the secret holder. There are
|
|
still a few details that could derail such a project, though.
|
|
|
|
Thank you for your atention.
|
|
|
|
Craig Milo Rogers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|