Linux-Development-Sys Digest #265, Volume #8 Wed, 8 Nov 00 17:13:20 EST
Contents:
Re: Kernel Mismatch Right out of the Box ("Cynthia M. Cooley")
Re: Files on NFS (Kaz Kylheku)
Re: cross-compile toolchain g++ (Bryan Hackney)
Re: Is that process a thread? (George MacDonald)
Re: writing a module for the kernel ("mamyx")
Re: Is that process a thread? (George MacDonald)
Re: linux doesn't detect my LNE100TX ethernet card (Tom Roberts)
how to use semaphores in the kernel (in a module) ? ("mamyx")
Re: Software RAID ("William Fong")
DVD-RAM support in Linux for reading/writing data (Blaise Canzian)
Normal file access in a kernel module ([EMAIL PROTECTED])
Re: Is that process a thread? (George MacDonald)
Re: non-portable port (George MacDonald)
Re: harddisk and partitions (George MacDonald)
mmap() vs. lseek() on /dev/mem (Gary Parnes)
Threads under c++ (Erwin Hogeweg)
FS: Compaq Docking Stations (futurebots)
----------------------------------------------------------------------------
From: "Cynthia M. Cooley" <[EMAIL PROTECTED]>
Subject: Re: Kernel Mismatch Right out of the Box
Date: Wed, 08 Nov 2000 09:15:45 -0800
> >Enough already. I install the damn thing and when I recompile my device
> >drivers from scratch, I get a
> >Kernel Mismatch warning error during installation. Saying the driver was
> >compiled for 2.2.16-22 and this kernel is 2.4.something.
It seems that the kernel source version is 2.2.16-22 while the kernel
headers are 2.4.something
for the RH 7.0 release.
I went ahead and compiled them and used the
insmod -f
option, which ignores the mismatch. Things seems to work fine at this
point, but indicates
more challenges with the RH 7.0 release.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Files on NFS
Reply-To: [EMAIL PROTECTED]
Date: Wed, 08 Nov 2000 16:41:08 GMT
On Wed, 8 Nov 2000 16:24:51 +0300, Ildar Gabdullin <[EMAIL PROTECTED]> wrote:
>Hello, all.
>
>How I can determine whether the file reside on NFS or not ?
man fstatfs
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: cross-compile toolchain g++
Date: Wed, 08 Nov 2000 11:12:22 -0600
Graduate wrote:
>
> Hi all,
>
[...]
Make sure you use the same configure switch everywhere to specify the
object format. Good luck. This is often a puzzle in my experience.
> I untar gcc-core- and gcc-g++- files and my coufigure command is
> configure --prefix=/usr/local/arm --target=arm-linux --host=i686-linux
> --with-cpu=strongarm110
> Config seems ok...
>
> then make LANGUAGES="g++", some time later, error occurs.
>
[...]
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://bhconsult.com/
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is that process a thread?
Date: Wed, 08 Nov 2000 17:55:18 GMT
Maciej Golebiewski wrote:
>
> [EMAIL PROTECTED] wrote:
> > |> Why not use PID/PPID relationships?
> > |
> > | Because this does not distinguish between processes created by fork and
> > | pthread_create, and while if they look the same for the system, the user might
> > | still be interested in distinguishing them (I had a few situations myself
> > | where
> > | it would help me).
> >
> > I presume in Linux that pthread_create() results in sys_fork() in the
> > kernel at some point. In order to distinguish if pthread_create() was
> > actually used to end up calling sys_fork() for a given process, you may
> > well have to look inside the process space for any markers left behind
> > by pthread_create() specific to the new thread. Keep in mind that a
> > thread may really call fork(), too, so the marker may get cloned.
>
> That was my first suggestion: to hack pthread_create so that it puts markers
> into the new threads environment and then you can look for them using
> /proc/#/environ
>
> It's a quick hack but should work.
If it were just for me then I would agree, however I am looking for a
solution that is in currently deployed distributions. If one were to modify
the generic kernel then a more comprehensive solution might be called for.
In particular some kind of kernel and process event/query mechanism.
Perhaps a /proc/kernel_agent that one could open, send requests to and
then read the responses. Requests could be of the form -> get/set value(s).
Some of the kernel modifiable values would be to enable notification
of kernel events(start/stop processes/threads)... Then monitor programs
such as treeps could open the agent, make requests for events and just
hang on a read waiting for kernel events...
The same model could be applied to processes via a /proc/#/agent
Most of the agent code could be put in a module, although some key
code would have to be scattered about the kernel. This would incur
some amount of overhead, perhaps it could be macro'ed so it would
be a build time option. I suppose would could also dynamically "patch"
the image to do debugger style watches, which would only incur overhead
when something was being monitored.
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: "mamyx" <[EMAIL PROTECTED]>
Subject: Re: writing a module for the kernel
Date: Wed, 8 Nov 2000 18:55:18 +0100
thanks for answer
yes the IPC functions are easy to use (I m not a GURU yet) , they meet my
requirements (parameters, error codes...) .(port of a driver from another
OS )
can I use them ?
should I use POSIX semaphores (for threads) : sem_init(), sem_wait(),...
or down-interruptible(), up() ....
how to use them ?
thank
xavier
"Rick Ellis" <[EMAIL PROTECTED]> wrote in message
news:8u9nf3$76i$[EMAIL PROTECTED]...
> In article <8u8uq8$k0l$[EMAIL PROTECTED]>, mamyx <[EMAIL PROTECTED]>
wrote:
>
> >can I use IPC System V utilities in modules (then in kernel code) ????
> >I want for example use semaphores and messages queues .
>
> Is there some special reason for wanting to use those facilities rather
> than the kernel's native functions?
>
> --
> http://www.spinics.net/linux
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is that process a thread?
Date: Wed, 08 Nov 2000 18:03:33 GMT
Maciej Golebiewski wrote:
>
> George MacDonald wrote:
>
> >
> > Can one lock pages in memory so they stay there even when all processes
> > die. Let's say I want to keep a shared lib in memory cause I know it's
> > going to be used again.
>
> If you're speaking of retaining shared libraries code in memory, than it's
> better to leave it to the kernel to decide when it makes sense.
>
> I think that kernel will unlock all pages when all processes referencing
> them die. IMHO it is the only reasonable thing for the kernel to do.
For general purpose computing I agree, however in a constrained environment
that is performing a dedicated function then it may make sense. For example
quasi real time situations where a watch dog triggers the death of a process
that is just going to be restarted again(perhaps after some other clean up).
>
> If you want to retain some data shared by all users of the library, you
> can do it by using SYSV shared memory, and letting the shared segment stay
> stale after all processes terminate. Then later new processes can shmat that
> segment again.
>
> If you don't like the idea of having stale segments hanging around (I don't)
> than you can add a small daemon that will be creator of that segment. Makes
> easier to decide which segments to delete when you run out of shmem and want
> to get rid of the stale ones :)
I agree with your approach, my question was more about the capabilities of
Linux specifically. Can Linux lock pages in memory, either at the kernel
level or in user land? Hmm, I think I'll go look at the code! How many
times have I done that now!!!
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: Tom Roberts <[EMAIL PROTECTED]>
Subject: Re: linux doesn't detect my LNE100TX ethernet card
Date: Wed, 08 Nov 2000 11:57:02 -0600
Sudhindra Suresh Bengeri wrote:
> I just isntalled kernel 2.2.17 hoping that it would have support for my
> LinkSys LNE100TX Fast Ethernet Adapter. But is didn't.
While I am not familiar with this specific card, I had a similar problem
with gatting Linux to use a cheap network card (LinkSys, I think).
As root I wrote a simple bash loop to run through every module in
/lib/modules/2.2.14-5.0/net
Most claimed no hardware, but one did.... It works just fine now.
Tom Roberts [EMAIL PROTECTED]
------------------------------
From: "mamyx" <[EMAIL PROTECTED]>
Subject: how to use semaphores in the kernel (in a module) ?
Date: Wed, 8 Nov 2000 19:11:22 +0100
is it possible to use the IPC System V functions (semget(),semctl()...)
the IPC functions are easy to use , they meet my requirements (parameters,
error codes...) BUT we are IN the kernel ?.....can I use them ?
should I use POSIX semaphores (for threads) : sem_init(), sem_wait(),...?
or down-interruptible(), up() ....
how to use them ?
thank
xavier
------------------------------
From: "William Fong" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,alt.linux,comp.os.linux.misc
Subject: Re: Software RAID
Date: Wed, 08 Nov 2000 18:17:53 GMT
Those cards are not really true hardware RAID devices. The only true EIDE
hardware RAID is from Adaptec. Those are in the $200 range.
-will
--
______________________________
William Fong - www.digitaldev.com
"David Sisk" <[EMAIL PROTECTED]> wrote in message
news:CacO5.40277$[EMAIL PROTECTED]...
> Setup no, operation yes. I'd suggest that you only use RAID0 as the O/S
> level, do anything else (RAID1, RAID5, RAID10) at the hardware level. If
> the box is doing any heavy work, RAID1, 5, or 10 will suck up lots of CPU
> and saturate the bus if you do it at the O/S level. Do it at the hardware
> level instead.
>
> There's an hardware adapter from 3ware.com that supports RAID0, RAID1, and
> RAID10 for IDE drives, is certified to work with Linux, and only costs
about
> $150 for the 2-channel model. There's also an IDE RAID adapter from ABIT
> (www.abit-usa.com) that's only about $50 for a 4 channel (!!!), their site
> states that it is supported by Linux, but the manual doesn't mention it.
> Anyone familiar with this?
>
> Regards,
> Dave
>
> U. Siegel <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hi folks,
> > anybody out there having experience with Software-RAID?
> >
>
>
------------------------------
From: [EMAIL PROTECTED] (Blaise Canzian)
Crossposted-To: comp.os.linux.hardware
Subject: DVD-RAM support in Linux for reading/writing data
Date: 8 Nov 2000 13:04:21 -0500
Is there support in Linux for reading and writing data (not movies,
music, etc.) to DVD-RAM? Is this kernel support? If not, are there
development/beta versions of Linux that incorporate or plan this
support? Is the support harware specific (Sony, Hitachi, Panasonic, etc)?
Thanks.
-- Blaise Canzian
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Normal file access in a kernel module
Date: Wed, 08 Nov 2000 19:50:37 +0100
I'm creating a kernel module for kernel version 2.2.16-22 Red Hat 7.0.
I want to access a normal file in the function "init_module" I know
the functions fopen, fprintf aren't available is there some
alternative.
Greetings
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is that process a thread?
Date: Wed, 08 Nov 2000 19:53:52 GMT
Maciej Golebiewski wrote:
>
> George MacDonald wrote:
>
> > One thing that seems to strongly indicate a thread is the presence of
> > one of these
> >
> > 40019000-40023000 r-xp 00000000 03:06 424368 /lib/libpthread-0.8.so
> >
> > entries in it's /proc/#/maps|
>
> Not really! Consider this: you have a process A that in its main thread
>
> pthread_create (...) ---> creates thread that is a process B
> fork () ---> forks process C
>
> Then /proc/#/maps for all A,B and C process (and the additional process which
> is the thread manager for A) will contain libpthread. So following your logic
> C would get classified as a thread for A (libpthread in maps nad PPID == A)
> even though it was fork'ed and not pthread_create'ed!
>
> Maciej
What is C then? If B was running in a thread context then so will C once it is
forked, no? Unless it calls routines to "end" that thread. If it does terminate the
"thread" will C then terminate the B thread?
It looks like there is some cooperation required by the B process, it needs to
behave properly? i.e. calling the right thread routines to fork/cleanup... So assuming
it does then you are correct that the pthread lib is still in the newly
forked childs mmap, even though it's not a thread!!! Grrrrrrrr
I wonder does anyone fork from a thread as you suggest? Even modfying the pthread
lib does not guarantee that a process does not call fork directly!
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-portable port
Date: Wed, 08 Nov 2000 20:07:28 GMT
Josef Moellers wrote:
>
> George MacDonald wrote:
> >
> > T wrote:
> > >
> > > I'd like to revive an old dos project that used inline assembly calls
> > > to BIOS and direct screen writes. Trying to get up to speed with Linux
> > > programming, I've been looking at some sources and reading what I can
> > > find. It looks like both (BIOS calls and direct screen writes) are
> > > verboten and in the domain of the Linux kernel. Learning about modules
> > > and kernel will take too long although I plan to keep at it. I looked
> > > at SVGALib, but my app doesn't need graphics-- it writes to text
> > > screen. Are there any viable approaches (other than give it up:~) and
> > > stuff like curses?
> >
> > Try
> >
> > man console_codes
>
> Just don't!
Hey dufus, read all of my posting(and understand it) before commenting. Perhaps
he wants to overlay graphics on top of what he is doing, or needs more
fine grained control over the screen than ncurses allows.
Especially read my last line! i.e. the reference to the *value* of using
ncurses!!!!!!!!!!! You never know how far and wide your program will be
used. One day all these X windows programs we use will probably be seen in
full 3D immersive environments!
Also the program he is talking about may only be used by himself, in
which case keeping things simple and easy to understand/implement is
also a very important consideration!!!
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: harddisk and partitions
Date: Wed, 08 Nov 2000 20:18:24 GMT
MESMEUR Philippe wrote:
>
> Josef Moellers wrote:
> >
> > MESMEUR Philippe wrote:
> > >
> > > Philip Armstrong wrote:
> > > >
> > > > In article <[EMAIL PROTECTED]>, Tux <[EMAIL PROTECTED]> wrote:
> > > > >MESMEUR Philippe wrote:
> > > > >> Hello, I'm looking for a way to get the list of the hard-drives an the
> > > > >> list for all the partitions in each hard-disk. I think the is a system
> > > > >> call to to this.
> > > > >What about "fdisk -l" ?
> > > >
> > > > Or cat /proc/partitions ?
> > >
> > > yes but I would like a function to do this (if there isn't, I
> > > will code it)
> >
> > ??? You want to write a function to retrieve information which is
> > already there ???
> > Hey, this is Linux, not any other OS!
> >
>
> I want to write a C-Program that needs to know all hard-disk on the
> current system and all partitions in each hard-disk;
> I can write a function that reads /proc/partitions or maybe, if it
> exists, I can use a function that does the same.
>
> Sorry if it was not clear.
> thanks to answer me
fp = popen("cat /proc/partitions", "r" );
Now can you do 3D pie's with wedgies?
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: Gary Parnes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: mmap() vs. lseek() on /dev/mem
Date: Wed, 08 Nov 2000 14:48:14 -0600
Okay, I don't know what subtlety I'm missing here...
I'm trying to access kernel memory from user space. A simple way to
access kernel RAM is, of course, using lseek() on /dev/mem as root.
lseek'ing lets me browse the virtual memory space on an x86 box (from
0xC0000000 up to end of RAM) quite nicely. But if I want to browse the
memory mapped portions of a PCI peripheral, I end up having to use
mmap() with the physical bus address of the PCI peripheral.
What I'm looking for is a common way to access both kernel RAM and PCI
memory space. The lseek technique doesn't seem to work in the PCI
memory space, and the mmap() technique doesn't seem to work in kernel
RAM space. I've tried playing with all sorts of permutations, but
nothing seems to work.
Why am I encountering problems?
Thanks in advance...
--Gary Parnes
[EMAIL PROTECTED]
------------------------------
From: Erwin Hogeweg <[EMAIL PROTECTED]>
Subject: Threads under c++
Date: Wed, 08 Nov 2000 16:45:18 +0100
Hi,
Where can I find documentation on how to use threads (linuxthreads)
under c++ with gcc 2.95 and kernel 2.2.16. I am looking fot tips and
tricks, gotcha's and compiler/linker switches.
Regards,
Erwin
------------------------------
From: futurebots <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
comp.dsp,comp.os.linux.development.apps,comp.os.linux.portable,comp.os.linux.hardware,comp.sys.powerpc.tech
Subject: FS: Compaq Docking Stations
Date: Wed, 08 Nov 2000 16:51:17 -0800
FS: Compaq docking stations for the LTE 5400, LTE 5300 series laptops..
$50.00 each + shipping
Regards
Dan Mathias
==========================
Future-Bot Components Web: http://www.futurebots.com
106 Commerce way, A8 Email: [EMAIL PROTECTED]
Jupiter, Fl. 33458 USA Phone/Fax (561) 575-1487
=======================================================================
Robotic and Electronic Components for the Hobbyist and Professional..
We have Motors, IC Chips, PC-Parts, Sensors, Robotic items......
------------------------------
** 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
******************************
