Linux-Development-Sys Digest #261, Volume #8 Tue, 7 Nov 00 16:13:15 EST
Contents:
Re: harddisk and partitions (Tux)
Re: problems compiling kernel module (Perego Paolo)
Driver upgrade problems (Alan L. Folsom, Jr.)
Re: Mouse Problem ("Daniel Lenski")
Re: Raw block device interface (Marc Tardif)
Re: Is that process a thread? (Kaz Kylheku)
Re: Is that process a thread? ([EMAIL PROTECTED])
Re: Raw block device interface (Philip Armstrong)
Re: harddisk and partitions (Philip Armstrong)
Re: Driver upgrade problems (Philip Armstrong)
about blocksize_size and hardsect_size (Richard)
Re: writing a module for the kernel (Rick Ellis)
Re: Is that process a thread? (George MacDonald)
Re: Is that process a thread? (George MacDonald)
Re: Is that process a thread? (George MacDonald)
----------------------------------------------------------------------------
From: Tux <[EMAIL PROTECTED]>
Subject: Re: harddisk and partitions
Date: Tue, 07 Nov 2000 15:52:33 +0100
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.
>
> Can you please help me. Thanks
>
> --
>
> --------------------------------------------------------
> Oce-Industries SA
> 1, rue Jean Lemoine
> 94015 Creteil cedex France
> phone: 33-1-48988000 fax: 33-1-48985450
> --------------------------------------------------------
What about "fdisk -l" ?
Tux
------------------------------
From: Perego Paolo <[EMAIL PROTECTED]>
Subject: Re: problems compiling kernel module
Date: 7 Nov 2000 15:11:17 GMT
Keith <[EMAIL PROTECTED]> wrote:
> I'm trying to compile a kernel module and for some reason I'm getting parse
> error before a bunch of structures defined in the types.h file. This file is
> included along with kernel.h, module.h, proc_fs.h. I tried re-arranging the
> order.
> I am using this to compile the module
> gcc -Wall -DMODULE -D__KERNEL__ -DLINUX -c proc_entry.c
Hi, you've to use also -O flag to expand "inline" functions! :)
> Help!!
--
$>cd /pub
$>more beer
Perego Paolo <[EMAIL PROTECTED]>
Tutor at D.S.I. - University of Milan
I'm Linux zion 2.4.0-test9 #2 Fri Oct 27 10:51:12 CEST 2000 i586 unknown
------------------------------
Subject: Driver upgrade problems
From: [EMAIL PROTECTED] (Alan L. Folsom, Jr.)
Date: Tue, 07 Nov 2000 16:17:56 GMT
Hi Folks-
I recently upgraded from RedHat 6.1 to 7.0, and am having problems
rebuilding a driver for it. I'm far from a guru in this, so please
excuse me if this should be obvious.
First problem was that MAP_NR macro was gone. I suspect this is
replaced by virt_page?
When compiling, I get a fairly cryptic message:
/tmp/ccDxfTBy.s:8: Warning: Ignoring changed section attributes for
.modinfo
Finally, when insmod'ing the driver, I get several unresolved symbols:
__release_region
__check_region
tasklet_hi_vec
bh_task_vec
__request_region
irq_stat
ioport_resource
I checked the region symbols, and they are still defined in ioport.h.
Any clues what I need to do here? Is there a document somewhere which will
let me know what changed, and what I need to do?
Thanks for any help
Al "clueless" Folsom
--
========================================================
Alan L. Folsom, Jr. Phone:215 343-6851
Warrington, PA [EMAIL PROTECTED]
"Before you criticize someone walk a mile in his
shoes. That way if he gets angry he'll be a mile
away -- and barefoot."
=========================================================
------------------------------
From: "Daniel Lenski" <[EMAIL PROTECTED]>
Subject: Re: Mouse Problem
Date: Tue, 07 Nov 2000 11:59:29 +0500
First of all, comp.os.linux.development.system is the wrong newsgroup for
this. Try comp.os.linux for example ...
But as for your question, what distribution of Linux are you using? What
graphical desktop environment are you using? Chances are you just have
to change a few X server settings ... let me know more about your
configuration and I'll try to help.
> Linux won't find my mini dinn mouse. It finds my mini dinn keyboard but
> not mouse. The mouse is not broken because it works in win98. I am a
> newbie at linux and don't know what to do. Can anyone help?
>
>
--
Daniel Lenski
[EMAIL PROTECTED]
"If we couldn't laugh at things that didn't make sense,
we couldn't react to a lot of the world around us."
--Calvin and Hobbes
------------------------------
Crossposted-To: comp.unix.programmer,comp.os.linux.networking
From: Marc Tardif <[EMAIL PROTECTED]>
Subject: Re: Raw block device interface
Date: Tue, 7 Nov 2000 12:10:17 -0500
> Is raw interface available in linux for block devices ?
> I have a partition and need to access it through a raw interface.
> Basically the aim of my program is to bypass the buffer cache and be
> assured that every read/write operation results into disk activity.
>
First, find the device name used by the "partition" you
want (use fdisk if you meant slice or disklabel if you
meant partition in it's non-confused meaning). Then add
an 'r' before the name. For instance, if your partition
happens to be ad0s1a (this is FreeBSD syntax, but you
get the idea: "s1" is the first slice, "a" is the first
partition in the slice). But you'll notice ls -l shows
/dev/ad0s1a as a block device, whereas /dev/rad0s1a
is the raw interface.. both to the same device. Note
that this no longer applies to FreeBSD which currently
only has raw interfaces to its devices, but you should
be alright on Linux.
Now when reading/writing to a raw device, you need to
make sure to do it in block sizes. I suggest you create
a slice with a few partitions to familiarise yourself
with the fdisk, disklabel and dd commands. Once you get
the hang of creating/deleting/reading/writing raw
partitions, you'll be less likely to overwrite valuable
filesystem information which can render a partition
unusable. Use with caution.
A simpler and more secure approach would be to use the
sync function which forces the completion of disk
writes.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Is that process a thread?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 07 Nov 2000 17:22:21 GMT
On Mon, 06 Nov 2000 20:35:49 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
>
>I was thinking that I could show threads with a different shape in the tree
>graph and then also have different menu items for threads.
Since this is just UI, some hack is probably good enough. Threads all have the
same name and are connected by a parent-child relationship. The main thread is
the parent of the thread manager, which is the parent of all other threads. If
you recognize that pattern and assume that it's threads, it should be ``good
enough''.
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is that process a thread?
Date: Tue, 07 Nov 2000 18:51:14 -0000
On Tue, 07 Nov 2000 14:52:44 +0100 Maciej Golebiewski <[EMAIL PROTECTED]> wrote:
|> | IMHO, what you wrote is a good argument for avoiding kernel modifications/new
|> | modules
|> | and limiting the changes to the pthreads library (so that it would mark the
|> | new threads
|> | in a way that would show up in the existing structure of /proc/#pid tree.
|>
|> 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.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: comp.unix.programmer,comp.os.linux.networking
Subject: Re: Raw block device interface
Date: 7 Nov 2000 18:53:01 -0000
In article <[EMAIL PROTECTED]>,
Marc Tardif <[EMAIL PROTECTED]> wrote:
>> Is raw interface available in linux for block devices ?
>> I have a partition and need to access it through a raw interface.
>> Basically the aim of my program is to bypass the buffer cache and be
>> assured that every read/write operation results into disk activity.
>>
>First, find the device name used by the "partition" you
>want (use fdisk if you meant slice or disklabel if you
>meant partition in it's non-confused meaning). Then add
>an 'r' before the name. For instance, if your partition
>happens to be ad0s1a (this is FreeBSD syntax, but you
>get the idea: "s1" is the first slice, "a" is the first
>partition in the slice). But you'll notice ls -l shows
>/dev/ad0s1a as a block device, whereas /dev/rad0s1a
>is the raw interface.. both to the same device. Note
>that this no longer applies to FreeBSD which currently
>only has raw interfaces to its devices, but you should
>be alright on Linux.
Unfortunately this is untrue for Linux. Until very recently, Linux has
not offered raw devices in the way that other unix-style operating
systems have.
You can of course access the block device directly, but it is not
possible in the current stable kernels to bypass the buffer cache
AFAIK.
However, recent development kernels have included the /dev/raw
character devices which can be bound to an arbitrary block device to
provide raw device semantics on that block device.
HTH,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: harddisk and partitions
Date: 7 Nov 2000 18:53:35 -0000
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 ?
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Subject: Re: Driver upgrade problems
Date: 7 Nov 2000 19:04:44 -0000
In article <[EMAIL PROTECTED]>,
Alan L. Folsom, Jr. <[EMAIL PROTECTED]> wrote:
>I recently upgraded from RedHat 6.1 to 7.0, and am having problems
>rebuilding a driver for it. I'm far from a guru in this, so please
>excuse me if this should be obvious.
oo. bad. .0 releases of RedHat have never had a good reputation and
7.0 is no exception.
>First problem was that MAP_NR macro was gone. I suspect this is
>replaced by virt_page?
err. This is still in the 2.2.17 kernel headers I have (according to
www.redhat.com, 7.0 ships with 2.2.16 + patches) so unless its been
patched away by RH, it should be in /usr/include/asm/page.h (or
linux/include/asm/page.h)
>When compiling, I get a fairly cryptic message:
> /tmp/ccDxfTBy.s:8: Warning: Ignoring changed section attributes for
>.modinfo
I think these are benign (Certainly I get them on my box
here). However, make sure you're compiling kernel stuff with the kgcc
which ships with RH 7.0 . RH shipped an unstable gcc version which is
unable to compile the kernel correctly as the standard gcc on 7.0 .
>Finally, when insmod'ing the driver, I get several unresolved symbols:
> __release_region
> __check_region
> tasklet_hi_vec
> bh_task_vec
> __request_region
> irq_stat
> ioport_resource
>I checked the region symbols, and they are still defined in ioport.h.
err. Not in my 2.2.17 kernel headers. These *appear* to be 2.4.0
prelease kernel functions. They're defined in my
System.map-2.4.0test9, but not System.map-2.2.17 for instance.
>Any clues what I need to do here? Is there a document somewhere which will
>let me know what changed, and what I need to do?
HTH some,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: Richard <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: about blocksize_size and hardsect_size
Date: Tue, 07 Nov 2000 03:06:51 +0800
I know that there are two information about block drivers
int blksize_size[][] - size of the block used by each device
int hardsect_size[][] - hardware sector size
what is the relationship between block size and hardware sector size ???
In buffer_head, there is a b_blocknr storing the block number and
b_rsector storing the real buffer location on disk. Is the b_blocknr
stands for block while b_rsector stands for the hardware sector??
However, the hardsect_size and blksize_size may differ. If that is the
case, the size of the buffer in buffer_head is a block size or hardware
sector size?
Thanks,
Marty.
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: writing a module for the kernel
Date: 7 Nov 2000 20:08:03 GMT
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: Tue, 07 Nov 2000 20:17:40 GMT
Alexander Viro wrote:
>
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> wrote:
>
> >Thanks, I read some of the kernel sources today and got a slightly better
> >handle on Linux threads implementation. I'm still a bit fuzzy on it, I'll
> >read some of the thread code to see what it does. I was kinda hoping that
> >there was some easy way to tell. Like the processes with
> >
> > The same name
> > Exactly the same memory maps
> > That are in a non-interupted hierarchy
> >
> >are threads.
>
> The last part is simply wrong - if child, parent and grandparent share VM
> and parent does exec() we get child and grandparent sharing VM and parent
> having a separate one. So non-interrupted hierarchy is not promised.
>
Depends on what's exec'ed, but I see your point. As long as there is shared
VM the process can be corrupted...
> Don't forget, there are other parts of process. E.g. you may have A
> sharing VM with B, B sharing descriptor table with C while A and C have
> nothing in common.
Thanks, it's becoming clear as mud!
--
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: Is that process a thread?
Date: Tue, 07 Nov 2000 20:42:29 GMT
Maciej Golebiewski wrote:
>
> George MacDonald wrote:
> > > Maybe you could modify the pthreads library, so that a special tag shows up in
> > > the new thread's environment and then identify threads by searching for those
> > > tags in /proc/#pid/environ ?
> >
> > Perhaps /proc/#pid/threads/#tid/...
> >
> > Then one could peer into the individual threads. Could a kernel module do
> > this?
>
> I'm not sure. If it is possible without modifying the kernel (e.g. no need to
> hook into clone() or whatever it is called now) then yes. On the other hand,
> the kernel evolves faster than pthreads, so having a module might mean more
> work to keep up with the new versions of the kernel...
The program typically has to be tweaked for each release anyhow! The config
engine is getting to be a project on it's own! It would be nice if the pthreads
lib could somehow pass down the info and then the /proc code cold be tweaked
just a bit. That will depend on distribution changes though and I'm looking for
a solution right now. It looks to me like the kernel code does not really know
that a process is a thread. I couldn't find anything in the major structures
that specifically says "Yah I'm a thread", perhaps is could be deduced.
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|
>
> > I was thinking that I could show threads with a different shape in the tree graph
> > and then also have different menu items for threads. I suppose the other approach
> > is to actually create a tree inside the "process" graphic. The former seems more
> > appropriate for Linux, while the latter might be more representative for Solaris...
>
> After reading your initial post, my first thought was about displaying threads
> with increased indentation under the process symbol. Don't know if it makes
> sense to you, though.
Yeah, interesting idea. I was thinking of just using rounded corners. I was also
thinking
about creating an overlapping stack of processes/threads when one parent has many
children that are the same. The stacking only works if the children have no further
descendents. One disadvantage to the File System(Indented) type tree is that it takes
up more
vertical space, something that's usually in short supply. Although I could drop the
"name" and just use a tiny bubble as the default representation. I do want to
support the drill down/extraction model so one can explore thread details(more for
other platforms). Longer term I also want to be able to drill into processes and
extract global variables...
--
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: Is that process a thread?
Date: Tue, 07 Nov 2000 20:56:33 GMT
Kaz Kylheku wrote:
>
> On Mon, 06 Nov 2000 20:35:49 GMT, George MacDonald <[EMAIL PROTECTED]> wrote:
> >
> >I was thinking that I could show threads with a different shape in the tree
> >graph and then also have different menu items for threads.
>
> Since this is just UI, some hack is probably good enough. Threads all have the
> same name and are connected by a parent-child relationship. The main thread is
> the parent of the thread manager, which is the parent of all other threads. If
> you recognize that pattern and assume that it's threads, it should be ``good
> enough''.
That + presence of pthread lib in the mem maps. Although I suppose someone
could statically link. I suppose the only way to know for sure is to look
inside the "process" and see if it was started as a thread and is still
"behaving" like one! Jeesh, it would be easier just to create a static
list that can be hand edited. Perhaps binding different shapes to those
in the list. Hmmm, kinda like skins but a bit more dynamic ---> "ShapeShifting"...
--
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)
------------------------------
** 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
******************************
