Linux-Development-Sys Digest #204, Volume #8 Tue, 10 Oct 00 10:13:11 EDT
Contents:
Re: system.map (Paul Kimoto)
Re: PCI Card access problems (driver) (Arne Driescher)
Re: Driver Loading FPGA Device (Mathias Waack)
Re: Driver Loading FPGA Device (Arne Driescher)
Re: A new directory hierarchy standard - need opinions (jtnews)
Re: A new directory hierarchy standard - need opinions (Bernhard Mogens Ege)
Re: Kernel 2.4.0-test7, 8, and 9 "Warning pasting would not give a valid
preprocessing token" ? (Nix)
Problems when installing mod_ssl-2.5.1-1.3.11 ("Green")
Where do actual block device/disk read&writes end up in the kernel (2.2) ?
ll_rw_blk.c ? ("Albert Siersema")
getting "struct pci_dev" from "struct netdevice" ("Anil Prasad")
utime(touch) gives EPERM - Bug in Linux??? (Dr. Peer Griebel)
Re: Kernel Mailing lists at Red Hat? (Giacomo Catenazzi)
Re: Network Drivers help! (Tasos Kotaras)
Re: Driver Loading FPGA Device ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: system.map
Date: 10 Oct 2000 01:45:45 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Frank Contrepois wrote:
> I'm trying to understand how system.map works
It doesn't _do_ anything per se. It is generated from the compiled kernel
(see the top-level Makefile) and is essentially the sorted output of nm(1).
It functions like a table of contents for the kernel, mapping between
memory locations and function names (from the source code).
Programs like ksymoops(8), klogd(8), and ps(1) use it to turn memory
addresses (obtained from the kernel) into human-readable names in their
output.
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: PCI Card access problems (driver)
Date: Tue, 10 Oct 2000 08:54:41 +0200
Heiko Bachmann wrote:
>
> Hi,
>
> I try to develop my first linux driver but ran into some problems. The books
> I have and online docs I've found couldn't give all answers so I hope you
> can :-)
>
> 1. I have the address of the card, 0xe300000. With ioremap() I get a remapped
> address, e.g. 0xc800..... Can I directly access data (pointer dereference)
> with that remapped address? Which of the addresses do I have to use with
> readb/readw/readl? I guess it's the latter one because the 0xe300... caused
> page faults?
0xc800.. is the right answer. But for PCI config register it is
recommended to use
the kernel functions. Read any recent drivery source to see how.
And don't forget /usr/src/linux/Documentation/IO-mapping.txt
> 2. This card uses 64MB PCI memory. After remapping, different access methods
> only returned 0xff for all probed values in that 64MB area. I have seen
> that other programmers use mem_map_reserve() for the PCI memory area. Is
> it neccessary in my case? I tried it but nothing changed.
Does the card provide its own memory or does it use PC RAM for its
purpose
e.g. bus master dma.
In the first case you should simply access the memory returned by
ioremap().
>
> 3. A HowTo at TUCOWS described that writing all 1's into a base address
> register and reading again gives the size of the mapped PCI memory. This
> procedure was not for i386 architecture. Testing on my i386 produced
> wrong sizes. Is there a chance to check the size, so that I can use this
> value for ioremap()? (There are two versions of that card, one with 64MB
> and one with a reduced mem. size of 64KB)
Again, use the functions provided by the kernel. Read Rubinis book as a
start.
> Thanks in advance!
>
> Heiko.
>
> P.S. The mentioned card is a PCI-60A IndustryPack(TM) holder with a
> PLX PCI9080 PCI controller chip. Maybe anyone has already heard about
> that... :-)
>
Hmm, wrote a driver for the PLX 9050 based card. Perhaps the difference
is not too big.
Have a look at
http://ifatwww.et.uni-magdeburg.de/~arne/me2600/index.htm
-Arne
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: Driver Loading FPGA Device
Date: 10 Oct 2000 08:53:38 +0200
Hi,
[EMAIL PROTECTED] (Pete Zaitcev) writes:
> On Mon, 09 Oct 2000 18:03:20 GMT, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > One of the first tasks the driver I am writing must do is to read a
> >.pof file off of the system disk and program a FPGA device on the
> >device board. This is for a PCI device but I am not sure that is
> >relevant to this situation. Does anyone have or know of any code
> >that implements this?
> >
> This is normally done with a helper application. The application reads
> the file, then issues an ioctl() into the driver that programs the
> FPGA.
Yes. Or another solution would be a writable /proc-file. So could just
use "cat" as your helper application.
Mathias
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: Driver Loading FPGA Device
Date: Tue, 10 Oct 2000 09:04:25 +0200
Pete Zaitcev wrote:
>
> On Mon, 09 Oct 2000 18:03:20 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > One of the first tasks the driver I am writing must do is to read a .pof
> > file off of the system disk and program a FPGA device on the device
> > board. This is for a PCI device but I am not sure that is relevant to
> > this situation. Does anyone have or know of any code that implements
> > this?
> >
> > Thank you.
>
> This is normally done with a helper application. The application
> reads the file, then issues an ioctl() into the driver that programs
> the FPGA.
>
> --Pete
This is certainly a good way. However, soemtimes this is not optimal to
the purpose.
For the final driver version you would rather try to provide a ready to
run solution
without extra overhead for the installation.
Way 1): Write a script to convert your .pof file into a hexdump and link
it to
the driver. See
http://ifatwww.et.uni-magdeburg.de/~arne/me2600/index.htm for
an example.
Way 2) See /usr/src/linux/drivers/sound/sound_firmware.c for how to
load files from kernel space.
-Arne
------------------------------
From: jtnews <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup,sci.crypt
Subject: Re: A new directory hierarchy standard - need opinions
Date: Tue, 10 Oct 2000 08:20:02 GMT
Ok, I see your point. However, how much different is this from
using HelixCode update? If you gain control of the central server
and everyone updates, everyone gets hosed. The only insurance
against this is the signature. If this is enough protection
then why can't a similar signature type system be developed for
entire directory hierarchies? Can NFS be enhanced so that
you can have signed directories based on something like gpg?
Alexander Viro wrote:
>
> Spoofing of all kinds. Wide-open to middleman attacks. Traffic analysis
> gives a _lot_ of interesting information. Any routing problems on major
> ISP immediately turn into massive DoS. Too many points where single failure
> brings a lot of damage. And server itself becomes extremely tasty morsel
> for every cracker on the planet - get in and you've got all clients.
> Could you spell "DDoS of really majestic proportions"? Could you spell
> "gain control over server, change the clients' idea of the IP of said
> server redirecting them to your mirror, then get the fsck out of server
> restoring everything in pristine condition"? Could you spell "mother of
> all class action lawsuits as soon as the shit will hit the fan"? Same
> applies for DNS spoofing, etc. The question with security problems is
> not "if", it's "when and how hard". Shit _will_ hit the fan and with your
> scheme consequences of a single compromise are going to be really nasty.
> Please, get real.
>
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
Crossposted-To: comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: A new directory hierarchy standard - need opinions
From: Bernhard Mogens Ege <[EMAIL PROTECTED]>
Date: Tue, 10 Oct 2000 08:25:03 GMT
>>>>> "Equinox" == Equinox <[EMAIL PROTECTED]> writes:
[snipped some stuff]
> 2) /opt/ seems to be a "Program Files"-like directory [please excuse
> the reference to Windoze] for the installation of software
> packages that don't fit neatly into the /usr/* and /usr/local/*
> hierarchies. Why, then, do we have /opt/bin/ , /opt/lib/ , and
> so forth?
At our university, we have a scheme were we put software in
/pack-{arch}, mount it in /pack on the machine having architecture
{arch}, link stuff in there into /coll/{department,beta,local}. Local
is for local installations, beta for new software (we usually dont
change software during mid-course) and department for software from
other departments. The main point is that software is linked into
/coll (collection) from /pack (which is linked from /pack-{arch} which
again could originate from elsewere).
Ok, so lots of symlinks/mounts are involved here, but it does work
(has so for years). We are mostly using Sun's (/pack-sol2) though (SGI
and Linux is second place).
The root of all packages usually contain bin/lib/src/man/info/include
directories (all depending on the package)
e.g. /pack/matlab/bin/matlab (where /pack/matlab is automounted from a
remote host). matlab is accessed via /coll/local/bin/matlab.
The PATH variable contains /coll/local/bin (and other /coll/* if
needed) and they are put at the end of the PATH env.
For each new package added, /coll is updated (I use depot).
> I could go on... Note that this little rant shouldn't be taken to
> mean that I have come up with all the answers, and can produce a draft
> for my idea of FHS 3.0 right now. I haven't, and I can't. But I'll
> let you know when I have and I can. :)
> Just my two cents worth.
I also see the need for a better structure. I dont like putting all
sorts of packages into /usr or /usr/local. It gets messy and it is
difficult to remove the program (if rpm or something similar isn't
used).
Bernhard Ege
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Kernel 2.4.0-test7, 8, and 9 "Warning pasting would not give a valid
preprocessing token" ?
Date: 10 Oct 2000 07:29:44 +0100
Robert Lynch <[EMAIL PROTECTED]> writes:
> Also, surprisingly (?) the 2.4.0-test9
> kernel come out MUCH smaller.
No surprise; the GCC development tree's optimizers are in flux in many
ways; with functions-as-trees, C and C++ common frontend code, and SSA
all pouring in at once. As a result the optimizers are not yet, er,
optimal.
--
`Naturally, a sysadmin's entire person is holy. We have the power to kill
daemons.' --- Mike Sphar
------------------------------
From: "Green" <[EMAIL PROTECTED]>
Subject: Problems when installing mod_ssl-2.5.1-1.3.11
Date: Tue, 10 Oct 2000 17:54:40 +0800
I have problem when I am installing mod_ssl-2.5.1-1.3.11. Woould you like to
help me?
My web server is Apache1.3.11, so I download mod_ssl-2.5.1-1.3.11 for
installation. Also I have installed openssl-0.9.5a and I think it is
successful.
The following is my step of installing mod_ssl-2.5.1-1.3.11:
Step 1)
After I enter
"./configure --with-apache=/usr/local/apache --with-ssl=/usr/local/src/opens
sl-0.9.5 --prefix=/usr/local/apached_ssl-2.5.1-1.3.11" in
/usr/local/src/mod_ssl-2.5.1-1.3.11 then the following message occurs
============================================================================
===============
Configuring mod_ssl/2.5.1 for Apache/1.3.11
+ Apache location: /usr/local/apache (Version
1.3.11)igure --with-apache=/usr/local/apache --with-ssl=/usr/local/src/mod_s
sl-2.5.1
+ OpenSSL location: /usr/local/src/openssl-0.9.5a
+ Auxiliary patch tool: ./etc/patch/patch (local)
+ Applying packages to Apache source tree:
o Extended API (EAPI)
o Distribution Documents
o SSL Module Source
o SSL Support
o SSL Configuration Additions
o SSL Module Documentation
o Addons
Done: source extension and patches successfully applied.
Configuring for Apache, Version 1.3.11
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Error: Cannot find SSL library files under /usr/local/src/openssl-0.9.5a
Creating Makefile in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ checking for system header files
+ adding selected modules
o ssl_module uses ConfigStart/End
+ SSL interface: mod_ssl/2.5.1
+ SSL interface build type: OBJ
+ SSL interface compatibility: enabled
+ SSL interface experimental code: disabled
+ SSL interface conservative code: disabled
+ SSL interface vendor extensions: disabled
+ SSL interface plugin: Built-in SDBM
+ SSL library path: /usr/local/src/openssl-0.9.5a
+ SSL library version: OpenSSL 0.9.5a 1 Apr 2000
Now proceed with the following commands:
$ cd /usr/local/apache
$ make
$ make certificate
$ make install
============================================================================
========
Step 2)
==========================
cd /usr/local/apache
==========================
Step 3)
/usr/local/apache # make
Then the following message occurs
============================================================================
========
===> src
make[1]: Entering directory `/usr/local/apache_1.3.11'
make[2]: Entering directory `/usr/local/apache_1.3.11/src'
make[2]: *** No rule to make target `all'. Stop.
make[2]: Leaving directory `/usr/local/apache_1.3.11/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/usr/local/apache_1.3.11'
make: *** [build] Error 2
============================================================================
=========
Anyone Know why?
------------------------------
From: "Albert Siersema" <[EMAIL PROTECTED]>
Subject: Where do actual block device/disk read&writes end up in the kernel (2.2) ?
ll_rw_blk.c ?
Date: Tue, 10 Oct 2000 12:56:08 +0200
After some digging around I thought that actual read/write actions for
block devices end up in ll_rw_block() in:
/usr/src/linux/drivers/block/ll_rw_blk.c (independant of the physical
device).
make_request() there probably asks the lower half (hardware dependant
driver)
to perform the read/write ?
Where does returned data from a completed read get back ?
end_that_request_first() ?
Is this correct and/or could someone enlighten me on the correct flow of
block device read/writes through the kernel ?
I've checked up on the various documents in the kernel Documentation tree as
well as the documents linked from there but couldn't find an alltogether
in-depth
description.
TIA,
Albert
(when replying by e-mail, and please do, strip the dot and capitalized
section please)
------------------------------
From: "Anil Prasad" <[EMAIL PROTECTED]>
Subject: getting "struct pci_dev" from "struct netdevice"
Date: 10 Oct 2000 11:37:05 GMT
hi,
i am writting a sort of generic pci driver.
my problem is that i have netdevice structure of a pci network card. i want
to obtain card's pci_dev structure in a kernel module. i could not find any
common field between these structures.only common member is irq which is of
no use as it can be used by more than one device.
------------------------------
From: [EMAIL PROTECTED] (Dr. Peer Griebel)
Subject: utime(touch) gives EPERM - Bug in Linux???
Date: Tue, 10 Oct 2000 11:54:36 GMT
Hi,
I just discovered that I can't successfully "touch" a file (I don't
own the file):
> ls -l myfile
-rw-rw-rw- 1 ralph users 123 Okt 10 13:46 myfile
> touch myfile
touch: myfile: operation not permitted
As you can see the file has write permission (the directory also). But
the file belongs to somebody else - not me. This error occurs in
2.2.10, in 2.2.14 - but not in 2.0.36.
So is this a valid reaction? I would like to be able to change the
modification time of the file. I would be able to do so by simply
writing to the file...
Thank You.
Peer.
------------------------------
Date: Tue, 10 Oct 2000 13:56:13 +0200
From: Giacomo Catenazzi <[EMAIL PROTECTED]>
Subject: Re: Kernel Mailing lists at Red Hat?
moscito wrote:
>
> Hello, I would like to re-subscribe to the kernel mailing list and
> some other lists; I understand that they are now being hosted at Red
> Hat. Can someone inform me where linux-kernel and linux-smp went?
vger.rutgers.edu -> vger.redhat.com -> vger.kernel.org
All the old lists should be in vger.kernel.org
check with majordomo@
>
> PS, can someone tell me where the redhat linux list themselves are ...?
giacomo
------------------------------
From: Tasos Kotaras <[EMAIL PROTECTED]>
Subject: Re: Network Drivers help!
Date: Tue, 10 Oct 2000 16:21:48 +0300
Kaz Kylheku wrote:
> On Mon, 09 Oct 2000 11:33:53 +0300, Tasos Kotaras <[EMAIL PROTECTED]> wrote:
> >Hello everybody
> >
> > Although I already have some experience in char device drivers, I
> >feel lost as far as network drivers making is concerned.
> >
> > My current task is to create an HDLC driver for linux. (I'm going to
> >use the on-chip capability of PPC860 for that). From what I have seen
> >from the kernel sources, the socket abstraction that is used for the
> >network
> >drivers seems to add awful lot of complexity and overhead. Given that
> >I'll be using it in an embedded set-up, this is an issue.
>
> Drivers are not based on any socket abstraction. Sockets are an interface that
> processes can use to talk to protocols or drivers; you can bind the right kind
> of socket to a driver to do packet level I/O. But the socket object exists
> independently of the driver, and the driver doesn't have to do anything special
> to make that work.
Sorry if I didn't make myself very clear. I do accept that sockets is something
above and beyond the nework driver. But you still have to pass (you or the kernel)
all the sockets burden to make a network driver useful (i.e. build a stack from
the
bottom (= net. driver) to the top (= application). As I checked in the kernel
sources,
the whole path is awfully long, complex, and therefore slow. My question is
whether
there is a chance to make it in a sipler way. (for example use proprietary objects
other
than skb, avoid hard-wired functions like net_fs, use another way - other than
sockets - to talk with the driver, etc.) It seems to me (pleasse tell me if I'm
wrong)
that there is no other way than use a (sophisticated?) character device, where I
have all the freedom to do what I want.
> > I would like to know if there is any way to avoid doing all this
> >fuss with the sockets.
>
> To write a network driver, you never have to touch sockets or even know what
> they are or that they exist. You just have to implement the network device
> driver interface, the core of which has to do with header construction and
> passing packets (struct sk_buff objects) up and down.
When I mentioned the word "fuss" I meant the work done by the kernel, not me.
> >An idea that crossed my mind was that I may use a
> >character device driver to do the job. I know that this will be a char
> >rather than
> >packet oriented solution, but with some additional effort it will be OK.
>
> If you have a datalink device that resembles a serial line, it may make sense
> to write a tty driver for it. Then your higher level datalink protocol like
> HDLC can be implemented as a tty line discipline which is independent of the
> driver. The line discipline can hook into the networking subsystem to appear as
> a network device.
This sounds interesting enough. Is there any formalism to do this? In the kernel
code
I noticed that there are functions like e.g. dev_add_pack that are used to hook
a protocol to a network driver. Is there any documentation on such issues?
I would be grateful if somebody could feed me with some pointers.
Thanx again
--
`\|||/
(@@)
_ooO_(_)_Ooo________________________________
______|_____|_____|_____|_____|_____|_____|_____|
_____|__________|_____|_____|____|_____|____|_____
|________Tasos Kotaras___|_____|____|_____|_____|
___|___|__Telecom Software Engineer_____|____|____
_____|_____Access Net & Wireless Comm Dept
|_______|___INTRACOM___|_____|______|______|____
__|___|______Peania 19002, Greece_|_____|____
___e-mail: [EMAIL PROTECTED]|____|____|____|
|_____Phone: +30 1 6690185_______|_____|______
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Driver Loading FPGA Device
Date: Tue, 10 Oct 2000 13:50:45 GMT
In article <[EMAIL PROTECTED]>,
Arne Driescher <[EMAIL PROTECTED]> wrote:
> Pete Zaitcev wrote:
> >
> > On Mon, 09 Oct 2000 18:03:20 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> > > One of the first tasks the driver I am writing must do is to read
a .pof
> > > file off of the system disk and program a FPGA device on the
device
> > > board. This is for a PCI device but I am not sure that is
relevant to
> > > this situation. Does anyone have or know of any code that
implements
> > > this?
> > >
> > > Thank you.
> >
> > This is normally done with a helper application. The application
> > reads the file, then issues an ioctl() into the driver that programs
> > the FPGA.
> >
> > --Pete
>
> This is certainly a good way. However, soemtimes this is not optimal
to
> the purpose.
> For the final driver version you would rather try to provide a ready
to
> run solution
> without extra overhead for the installation.
> Way 1): Write a script to convert your .pof file into a hexdump and
link
> it to
> the driver. See
> http://ifatwww.et.uni-magdeburg.de/~arne/me2600/index.htm for
> an example.
> Way 2) See /usr/src/linux/drivers/sound/sound_firmware.c for how to
> load files from kernel space.
>
> -Arne
>
Thanks to all for your input.
Our home grown board has two devices on it a CPLD (that will be
programmed by the time I get it) and an Altera FPGA EPF10K100A (to be
programmed). We will have a .pof file on the system disk that needs to
be written across the PCI interface, the CPLD program contains a serial
interface emulation to clock the .pof image into the FPGA a byte at a
time. This provides a dynamic aspect to the board.
This is the first time we are trying this, previously there was a EEprom
with the image for the FPGA and no OS.
-Eric
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
