Linux-Development-Sys Digest #100, Volume #7 Tue, 24 Aug 99 15:13:52 EDT
Contents:
Question about modules (Fernando Ortega Bellosta)
Re: TAO: the ultimate OS (Thomas Steffen)
Re: Netgear FA310TX (Dave Platt)
Re: C++ templates: More than Turing Complete? (Ulrich Weigand)
Re: Jesus: the ultimate OS ("Christopher R. Thompson")
MkLinux PCI support ("G. Angus McCollum")
spin lock (David Lee)
Re: How can I make device driver module to support many version of (Tim Hall)
Re: Compile problem with kernel 2.2.11 (Robert Krawitz)
Re: MPEG2 support for Linux ? ("Clemence")
SysV shared memory - how to distill the bus address? (Sidney Cadot)
Re: How can I make device driver module to support many version of (Peter
Samuelson)
Re: SysV shared memory - how to distill the bus address? (Marcus Sundberg)
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: How can I make device driver module to support many version of kernel?
(Eric Hegstrom)
----------------------------------------------------------------------------
From: Fernando Ortega Bellosta <[EMAIL PROTECTED]>
Subject: Question about modules
Date: Tue, 24 Aug 1999 12:44:30 +0200
Is it possible to make a module with different functions to be used by the
kernel?, the idea is to put one of my functions in the middle of the
kernel source.
I tried it but when I compile the kernel , it does not recognize my
functions.
How can I do it?
Thanks in advance, Fernando Ortega
------------------------------
From: Thomas Steffen <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 24 Aug 1999 11:00:48 +0200
[EMAIL PROTECTED] (Vladimir Z. Nuri) writes:
> realization of Tao
>
> Tao will be difficult to realize! Many aspects of its design may seem
> technically unrealistic, infeasible, or even impossible. Yet it is
> clearly a highly desirable OS in theory with aspects that far
> transcend even the best current OSes.
If it is as brialliant a design as you claim, it shouldn't be too
difficult to realise. There have been a few complex and elegant OSes
written from scratches with very little effort in a past. Lisp
probably was the first that should be included, though i know little
about its first implementation. Oberon certainly was one (in 1 1/2 man
years). Smalltalk might count, thought it is probably a bit more
complex, as is Java.
You can see that most of these OSes lacked significant aspect in the
first cut, like real multitasking, file systems, security, some even
networking, and still they were immediately useful.
*If* you can write a prototype to demonstrate the advantages
(e.g. persistent objects *are* extremely convenient, if you can rely
on them), then the missing part will be filled in. If you can't, then
probably the concept is wrong, and you wont be able to realise it
anyway.
PS: Convenience for the developer is as important as convenience for
the user, since applications have to be written somehow :-)
--
We regret to announce that Windows 2000 wont be ready before 1901.
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Crossposted-To: comp.os.linux.networking,comp.os.linux.hardware,linux.dev.net
Subject: Re: Netgear FA310TX
Date: Mon, 23 Aug 1999 20:16:03 GMT
In article <[EMAIL PROTECTED]>,
Rich Carreiro <[EMAIL PROTECTED]> wrote:
>Have you tried using the "patched" Tulip driver that Netgear/BayNetworks
>provides on their current driver disks (and is avail on their website)?
Yup. Didn't seem to do diddly to address the problem.
As best as I could tell, the biggest change in the Netgear driver was
a bit of added code to specifically recognize the version of the PNIC
chip they're OEMing, and report the card as a Netgear. There didn't
seem to be any real, substantial changes in their driver w/r/t
compatibility, or to deal with this nasty bug. And, as other folks
have noted, Netgear doesn't always keep their patched driver up to
date w/r/t Don Becker's latest version... and so in many ways the
"patched" Netgear driver is often out of date.
There was some discussion on the tulip-bugs mailing list of the actual
cause of the bug. It's pretty messy - it appears that when the chip
gets confused, it dumps a whole bunch of incorrect stuff into the
receive ring buffers without regard to proper packet boundaries.
One guy working on FreeBSD has implemented a large and hairy patch for
the problem. His fix, if I recall correctly, involves going out into
the buffers full of gunk deposited by the chip, scanning through them,
locating and parsing the packet headers and FCS/CRCs in software, and
actually reconstructing the original packets! Once this is done, his
patch resets the chip and reinitializes the ring buffers.
I was sufficently daunted by the complexity of this patch that I
haven't made any attempt to crossport it into the Linux driver.
A less expensive workaround for the problem would simply be to recognize
the symptoms of the chip error and reset the chip, discarding the
damaged packets (and potentially dropping transmit packets on the
floor). It would be up to the higher layers in the protocol stack to
recover from the loss of data. I did something like this a few years
ago to fix the AMD "lance" driver so that it would recover from
busmastering errors.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: [EMAIL PROTECTED] (Ulrich Weigand)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates: More than Turing Complete?
Date: 24 Aug 1999 15:00:11 +0200
David Schwartz <[EMAIL PROTECTED]> writes:
> No, it's a defect in the example. If templates are Turing complete, it
>is theoretically possible to create examples of C++ code that, while
>legal, can never be compiled into valid code because the existence of
>the valid code would be logically equivalent to a proof that the
>compilation could not terminate.
Not really. Any particular C++ program (with or without templates) might
have an undecidable halting problem (which in this case means: the problem
"given input X, decide whether that program, when started with input X,
halts or doesn't" is not computable). Nevertheless, the C++ program will
compile to an assembly code program which *itself* has an undecidable
halting problem.
> If C++ is turing complete, it should be possible to construct similarly
>self-referencial pieces of code. They would be syntactically valid.
>Obviously, they could not be compiled.
Eh? C++ is of course Turing complete, but so is every assembly language
to which it might be compiled ... I don't know of *any* programming
language in real use that is *not* Turing complete, b.t.w.; there isn't
really much that is necessary to achieve Turing completeness (if you
have something like elementary arithmetic, assignment, and conditional jump,
that's already enough ...).
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
------------------------------
From: "Christopher R. Thompson" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: Mon, 23 Aug 1999 16:01:16 -0700
Selious wrote:
>
> > I'm going to name my OS "Jesus". It will coded primarily to destroy all
> > "EVIL" objects os's and computers. Only the objects that "LOVE" Jesus
> > will survive and communicate with "Jesus".
>
> OK, my OS, named Gates, is going to represent the evil in society...
>
> Let's see who wins, hehehe
>
Truly sir: Only those who love Jesus will live to see the Glory.
TfJC.Com: up 67 days, 9:14,
> --
> pii350.ntdom: up 24 days, 22:55,
> linux.ntdom: up 118 days, 22:33,
> nw411.ntdom 112 days, 14:31
> nwtest.ntdom 123 days, 20:57
> alpha.ntdom: 1:06am up 59 days,
> linux4.ntdom: up 105 days, 58
> freebsd.ntdom: up 19 days, 3:03,
------------------------------
From: "G. Angus McCollum" <[EMAIL PROTECTED]>
Subject: MkLinux PCI support
Date: Tue, 24 Aug 1999 09:57:18 -0400
I am attempting to compile the tulip driver into the DR3 MkLinux kernel. The
process halts when doing the final link of the kernel. The pci functions
declared in bios32.h are not implemented. There are however pci functions,
not the bios32.h ones, in the mach micro-kernel source. Do I need to port
the driver's pci functions to use the mach pci functions(or implement
bios32.c)? Has anyone done this yet?
Thank you,
Angus
------------------------------
From: [EMAIL PROTECTED] (David Lee)
Subject: spin lock
Date: 24 Aug 1999 13:39:28 GMT
Hi there,
Is there any documentaton about how to use those spinlock
kernel functions?
Thanks in advance!
--
David Lee
------------------------------
From: Tim Hall <[EMAIL PROTECTED]>
Subject: Re: How can I make device driver module to support many version of
Date: Tue, 24 Aug 1999 10:16:53 -0400
Eric Hegstrom wrote:
> Peter Samuelson wrote:
> >
> > The only people seriously inconvenienced are those who would
> > distribute closed-source drivers.
> >
>
> Well it can be pain even if you have the source code really.
>
> --
> Eric Hegstrom .~.
> Senior Software Engineer /V\
> Sonoran Scanners, Inc. // \\ L I N U X
> [EMAIL PROTECTED] /( )\ >don't fear the penguin<
> 520-617-0072 x402 ^^-^^
An excellent point..
I just started on a project to develop PCI and ISA drivers for a variety
of computer telephony DSP cards. There have been substantial changes in
the PCI access functions since 2.0. Therefore, we had to make a decision
whether to have a lot of conditional compilation code or limit our driver
to support a given set of kernel releases.
The rapid ongoing of Linux is a mixed blessing. Great for people who need
support for more and more devices, a pain for those folks actually
providing the driver code.
Yes, I know a lot of Linux developers will take exception to this, but
this 'feature' could cause longterm problems in having hardware
developers providing Linux support for their boards.
Tim Hall
Senior Software Engineer
Natural MicroSystems
[EMAIL PROTECTED]
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: Compile problem with kernel 2.2.11
Date: 10 Aug 1999 21:12:27 -0400
Erik de Castro Lopo <[EMAIL PROTECTED]> writes:
> I just got the new stable kernel (2.2.11) from one of the
> mirror sites and got the following compile problem. I did
> the usual make xconfig ; make dep ; make.
>
> Compiler is gcc-2.95 but I also tried gcc-2.7.2.3 and got
> the same problem. Does anybody have any solution to this?
> /usr/src/linux-2.2.11/include/linux/pagemap.h:17: `PAGE_OFFSET_RAW' undeclared
>(first use this function)
One of the early menu items is to choose your maximum memory size.
It's not set to anything by default; you have to pick something (1 GB
is the most common).
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: "Clemence" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: MPEG2 support for Linux ?
Date: Wed, 25 Aug 1999 00:39:36 +0800
Try Loki Games (www.lokigames.com) or MpegTV SDK website (www.mpegtv.com)
Require at fast PC for the software decode.
Regards,
Clemence.
Alex Luk wrote in message <[EMAIL PROTECTED]>...
>Hi,
>
>Could you please tell me where can i find the MPEG1 player and development
kit
>for Linux? We are currently working on a Video-On-Demand project on Linux
>project, we really need some help on MPEG decoder on Linux.
>
>Thanks in advance.
>
>Alex Luk
>The Chinese University of Hong Kong
>
>
>Clemence wrote:
>
>> Hi,
>> I am aware that there are Mpeg1 players and development kit for Linux.
But
>> how are Mpeg2 player and development kit ? Is there any plan or release
>> date for such Mpeg2 support on Linux ?
>>
>> Your reply is appreciated.
>> Clemence.
>
------------------------------
From: Sidney Cadot <[EMAIL PROTECTED]>
Subject: SysV shared memory - how to distill the bus address?
Date: Tue, 24 Aug 1999 16:40:54 +0200
Hi all,
In a testbed system, I have a Pentium and tree VLIW CPU's hooked up to the PCI
bus; the VLIW CPU's are capable of bus-mastering.
I want to be able to execute programs in parallel on those four CPU's;
furthermore, I'd like to be able to start several programs on the Pentium in
order to create several "virtual processors". At program-start, I need to
exchange buffer addresses in order to be able to do inter-processor
communication later on (using either VLIW-CPU based DMA or memcpy()'s).
In order to exchange this bootstrap information, I need a small buffer (one 4K
page is more than enough) that is accessible from all participating processes
on the Pentium and also from the VLIW CPU's. SysV IPC shared memory is quite
ideal insofar as the Pentium-side of things is concerned: I can have a
permanent page of IPC shared memory, safely made non-swappable, and easily
accessible from each of the Pentium-based processes. All this can be
accomplished from within user-space (the setting up of a non-swappable shared
memory page is done by a setuid root program which does just that).
In order to access that page from the other CPU's however, I will need to
obtain the bus-address of this page. Does anybody know of a way to obtain this
bus address of a page of SysV IPC shared memory from within user-space?
Thanks in advance,
Sidney Cadot
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: How can I make device driver module to support many version of
Date: 24 Aug 1999 12:05:53 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Tim Hall <[EMAIL PROTECTED]>]
> I just started on a project to develop PCI and ISA drivers for a
> variety of computer telephony DSP cards. There have been substantial
> changes in the PCI access functions since 2.0. Therefore, we had to
> make a decision whether to have a lot of conditional compilation code
> or limit our driver to support a given set of kernel releases.
There are always tradeoffs. The obvious alternatives:
* Not develop as fast. Sorry....
* Develop as now but never make incompatible changes. Unfortunately
everyone's hands are forever tied by bad design decisions, and no old
stuff can ever get "cleaned up". This is a problem the Microsoft OS
groups are always having to face and nobody envies them for it.
* Define a "compatibility layer" either now or whenever something
changes, which is more or less guaranteed *not* to change. This is
what libc provides (so that, for example, if the pre-2.2 version of
the `umount' system call is ever dropped, programs that use it will
still run fine so long as a semi-recent libc is installed). The idea
here is that the libc layer would have a kernel-mode equivalent.
Linus is adamantly opposed to this, though. He believes that such a
layer is needlessly inefficient, complex at the source level, and
still ends up tying your hands.
> The rapid ongoing of Linux is a mixed blessing. Great for people who
> need support for more and more devices, a pain for those folks
> actually providing the driver code.
Unless you're someone like Cyclades, who contributes their own drivers
to the stock kernel tree where they tend to get updated whenever major
interface changes come down the pipe. And then, although they provide
most of the driver updates, at least they don't have to worry about
providing their customers with the "correct" version of the driver --
it's in the "correct" source tree already.
> Yes, I know a lot of Linux developers will take exception to this,
> but this 'feature' could cause longterm problems in having hardware
> developers providing Linux support for their boards.
Note that the issue at hand was not source-level compatibility (like
the PCI BIOS stuff you mentioned) but binary compatibility.
Source-level compatibility is actually quite good within a given stable
release cycle (like 2.0.* or 2.2.*). However, *binary* compatibility
is not, so if you're reticent about giving out your driver source, you
have to compile for individual releases and SMP/non-SMP. The AFS
people complain about this occasionally.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Marcus Sundberg <[EMAIL PROTECTED]>
Subject: Re: SysV shared memory - how to distill the bus address?
Date: Tue, 24 Aug 1999 20:07:19 +0200
Sidney Cadot wrote:
> In order to access that page from the other CPU's however, I will need to
> obtain the bus-address of this page. Does anybody know of a way to obtain this
> bus address of a page of SysV IPC shared memory from within user-space?
No, it isn't.
But it should be fairly simple to write a kernel driver that exports
a character device with a single ioctl(). This ioctl would take a
logical address as argument and return the corresponding physical
address and/or bus-address (which may be different depending on your
platform).
//Marcus
--
===============================+====================================
Marcus Sundberg | http://www.stacken.kth.se/~mackan/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 24 Aug 1999 18:16:50 GMT
In comp.os.misc Thomas Steffen <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Vladimir Z. Nuri) writes:
: If it is as brialliant a design as you claim, it shouldn't be too
: difficult to realise. There have been a few complex and elegant OSes
: written from scratches with very little effort in a past.
ah, but surely we can assert that the more brilliant & visionary
the design, the more difficult it is to pull it off, typically..
not so much because of the code, but because of the psychological
resistance to it. I tend to agree that it will be both easy
and hard. hard, to get people to agree on the vision. easy, once
people see the vision. an appropriate taoist paradox.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: Eric Hegstrom <[EMAIL PROTECTED]>
Subject: Re: How can I make device driver module to support many version of
kernel?
Date: Tue, 24 Aug 1999 11:04:29 -0700
Within a release cycle yes. Across a release cycle (lets say 2.0.x to
2.1.x) there are some very non-trivial changes. I think this is the
concern that Tim was refering to. I think concerns with longterm
migration are very valid. I have had to make the tradeoff myself.
-Eric
Peter Samuelson wrote:
> Source-level compatibility is actually quite good within a given stable
^^^^^^
> release cycle (like 2.0.* or 2.2.*). However, *binary* compatibility
> is not, so if you're reticent about giving out your driver source, you
> have to compile for individual releases and SMP/non-SMP. The AFS
> people complain about this occasionally.
--
Eric Hegstrom .~.
Senior Software Engineer /V\
Sonoran Scanners, Inc. // \\ L I N U X
[EMAIL PROTECTED] /( )\ >don't fear the penguin<
520-617-0072 x402 ^^-^^
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
