Linux-Development-Sys Digest #259, Volume #8 Mon, 6 Nov 00 21:13:15 EST
Contents:
Re: ext2 undelete (Kasper Dupont)
Re: nanosleep in kernel code (Kasper Dupont)
mounting CRAMFS as root
Re: Is that process a thread? (Maciej Golebiewski)
MOSIX with Gentus ("Allan West")
Re: PCI device to device DMA transfer (Pat Kling)
Re: nanosleep in kernel code ([EMAIL PROTECTED])
>2GB process memory (Andre Rohe)
Re: >2GB process memory ("Peter T. Breuer")
Porting driver source from 2.2.14 to 2.2.16 (Ed Hudson)
Re: Is that process a thread? (George MacDonald)
masq module question ("Daniel Lenski")
Re: Can I create a floppy with a simple Linux? (Markku Kolkka)
Re: Porting driver source from 2.2.14 to 2.2.16 (Pete Zaitcev)
Re: Is that process a thread? ([EMAIL PROTECTED])
Re: Porting driver source from 2.2.14 to 2.2.16 (Bill Waddington)
Re: Is that process a thread? (Alexander Viro)
HOWTO: Redhat Kernel Customization mini-HOWTO (Kaelin Colclasure)
----------------------------------------------------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: ext2 undelete
Date: Mon, 06 Nov 2000 12:11:22 +0100
MENON Jean-Francois wrote:
>
> hello
>
> I'm working on a kind of undelete for ext2 fs. I would like to know if
> there is other people working on the same problem.
> I would like to know how I can override the "unlink" function with my
> own function?
> (my "rm" command already works) It seems to be somthing with ldconfig,
> but I'm not sure.
>
> many thanks,
>
> jf
I think the best way to do this is by implementing a new
filesystem with an undelete feature build in. The filesystem
could be made by modifying ext2 and adding some extra data
structures to hold information about deleted files. The
filesystem of course should reuse the space as needed by
overwriting the oldest deleted file info. Increasing the 5%
reserved space might be a good idea as that space without
problems can be used for deleted file info.
Restoring files will still require a special utility which
for security reasons will require root access. The utility
could use some special ioctl's or similair.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: nanosleep in kernel code
Date: Mon, 06 Nov 2000 13:13:29 +0100
Tux wrote:
>
> Hi,
>
> I need a function which provides nano-sleep in kernel code, but I don't
> want to use the structures from linux/timer.h 'cause they're too complex
> for my needs. Just a function that halts my driver for specific numbers
> of milliseconds.
> Any ideas?
>
> Tux
Perhaps mdelay can be used.
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] ()
Subject: mounting CRAMFS as root
Date: 6 Nov 2000 11:25:14 GMT
I would like to mount cramfs as root filesystem. Would it be possible ?
My situation is that I've created a cramfs image populating at certain
address of ROM. And I want the kernel to mount it at the address directly
without loading into my precious limited memory just as ramdisk does.
Please help me.. thank you very much..
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Subject: Re: Is that process a thread?
Date: Mon, 06 Nov 2000 15:13:34 +0100
George MacDonald wrote:
>
> Is there an easy way to figure out if a process is a thread? I'm thinking
> about adding a new visual representation for threads in treeps. i.e.
>
> http://www.slip.net/~gmd/tps/treeps.htm
>
> but need a quick way to figure out if an entry in /proc is a thread.
I think that the only way to check if two two entries in /proc are two threads
of the same process is to verify that they share the same address space. But
I'm not sure if there is enough information in /proc to do it... Maybe not.
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 ?
I think grouping threads of the same process together could be a very useful
feature
in treeps (or any other tool showing the processes).
Maciej
------------------------------
From: "Allan West" <[EMAIL PROTECTED]>
Subject: MOSIX with Gentus
Date: Mon, 6 Nov 2000 14:29:39 -0000
Before I spend weeks patching up a kernel to work with MOSIX and take full
advantage of my Abit BE6XXXX boards has anyone already done this.
Regards,
Allan
mail at p r b o x dot com
------------------------------
Subject: Re: PCI device to device DMA transfer
From: Pat Kling <[EMAIL PROTECTED]>
Date: Mon, 06 Nov 2000 17:43:28 GMT
[EMAIL PROTECTED] writes:
> Hi All,
> I have a simple question.
> Does linux allow DMA transfer between two PCI device. (without
> involving the CPU). I know that NT doesn't support this but does Linux?
>
NT can be made to transfer between 2 PCI devices on the same PCI bus.
This can be done without even without having the source for one of
the devices. (which is convenient since source for NT drivers in
rarely available)
For example, suppose that you'd like to send data from a high speed
acquisition PCI card directly to disk. Further suppose that you do
not wish to mess around with the filesystem and SCSI drivers.
First map the acquisition card into the virtual address space of
a process. Then call WriteFile() passing the virtual address to
which you mapped the acquisition card. When you open the file,
make sure that you disable filesystem caching for this file.
The stock Linux kernel, unfortunately, does not support this
arrangement since its ruling class of developers has not included
an equivalent to NT's DirectIO. There are patches that allow this
functionality, but it's not a stock Linux kernel.
Pat Kling
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: nanosleep in kernel code
Date: Mon, 06 Nov 2000 17:45:11 GMT
You can also use select(2) for millisecond timeouts:
struct timeval timeout = { SECONDS, MILLISECONDS };
select (0, NULL, NULL, NULL, &timeout);
This isn't necessarily less complex, but it is at least reasonably
portable.
--Justin
In article <[EMAIL PROTECTED]>,
Kasper Dupont <[EMAIL PROTECTED]> wrote:
> Tux wrote:
> >
> > Hi,
> >
> > I need a function which provides nano-sleep in kernel code, but I
don't
> > want to use the structures from linux/timer.h 'cause they're too
complex
> > for my needs. Just a function that halts my driver for specific
numbers
> > of milliseconds.
> > Any ideas?
> >
> > Tux
>
> Perhaps mdelay can be used.
>
> --
> Kasper Dupont
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre Rohe <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: >2GB process memory
Date: Mon, 06 Nov 2000 19:25:03 +0100
Hello,
we have a 2GB memory and 2GB swap-space machine here, and I would like
to address about 3GB of memory in one process. We tried the standard Suse 7.0
kernel and 2.4.0 test9 (we tried the 4GB and 64GB memory option).
We never managed to malloc >2GB in one process. We also tried to play
with shared memory, but nothing worked.
Can somebody tell me what we do wrong ? Do we need more swap space ?
Thanks in advance
Andre
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: Re: >2GB process memory
Date: 6 Nov 2000 18:38:58 GMT
In comp.os.linux.misc Andre Rohe <[EMAIL PROTECTED]> wrote:
: We never managed to malloc >2GB in one process. We also tried to play
: with shared memory, but nothing worked.
It's not surprising, since the SuSE kernel is configured for 1G/3G
split between user and kernel.
: Can somebody tell me what we do wrong ? Do we need more swap space ?
You failed to look hard when configuring and compiling your kernel:
choice 'Maximum Physical Memory' \
"1GB CONFIG_1GB \
2GB CONFIG_2GB" 1GB
Peter
------------------------------
From: Ed Hudson <[EMAIL PROTECTED]>
Subject: Porting driver source from 2.2.14 to 2.2.16
Date: Mon, 06 Nov 2000 14:09:28 -0500
I have written a kernel module that builds and runs fine under kernel
2.2.14 and also was tested on 2.0.33. I have found that when I try to
build it under 2.2.16 and 2.2.17 I get a nearly endless stream of
errors. One that seems to appear quite frequently is in time.h... a
parse error before time_t in line 10. Many of the same types of
errors occur in xxx_fs.h where every filesystem under the sun is
represented by the 'xxx'. The common thread to this problem seems to
be the inclusion of <asm/uaccess.h>. Has something changed in this
file? If so, any ideas how I can work around this?
Thanks,
Ed
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is that process a thread?
Date: Mon, 06 Nov 2000 20:35:49 GMT
Maciej Golebiewski wrote:
>
> George MacDonald wrote:
> >
> > Is there an easy way to figure out if a process is a thread? I'm thinking
> > about adding a new visual representation for threads in treeps. i.e.
> >
> > http://www.slip.net/~gmd/tps/treeps.htm
> >
> > but need a quick way to figure out if an entry in /proc is a thread.
>
> I think that the only way to check if two two entries in /proc are two threads
> of the same process is to verify that they share the same address space. But
> I'm not sure if there is enough information in /proc to do it... Maybe not.
>
> 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 think grouping threads of the same process together could be a very useful
> feature
> in treeps (or any other tool showing the processes).
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...
--
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: "Daniel Lenski" <[EMAIL PROTECTED]>
Subject: masq module question
Date: Mon, 06 Nov 2000 16:28:22 +0500
when the register_ip_masq_app(..., __u16 port) function is called to
register an ip masquerading module, what exactly does the port parameter
specify? does it specify a port on the local computer to monitor, or does
it specify a port on the remote connections to monitor? i'm very confused
by this ... i'm having trouble figuring out in which cases my packet
interceptor functions actually get called. any help would be appreciated!
--
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
------------------------------
From: Markku Kolkka <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.questions
Subject: Re: Can I create a floppy with a simple Linux?
Date: 06 Nov 2000 23:51:02 +0200
Alan Po <[EMAIL PROTECTED]> writes:
> 2. When I try to use lilo "lilo -v -C lilo.conf -r /mnt/floppy", it say the
> zImage too big. I think the reason is the kernel size of 2.2.17 to too big
You should make bzImage instead of make zImage.
--
Markku Kolkka
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: Porting driver source from 2.2.14 to 2.2.16
Date: Mon, 06 Nov 2000 22:54:56 GMT
Very mysterious report. Many of my drivers use <asm/uaccess.h>
with no problems. I think that you would do right to post
several starting lines from the endless stream of errors that you get.
But for heaven's sake don't post the whole thing :)
--Pete
On Mon, 06 Nov 2000 14:09:28 -0500, Ed Hudson <[EMAIL PROTECTED]> wrote:
> I have written a kernel module that builds and runs fine under kernel
> 2.2.14 and also was tested on 2.0.33. I have found that when I try to
> build it under 2.2.16 and 2.2.17 I get a nearly endless stream of
> errors. One that seems to appear quite frequently is in time.h... a
> parse error before time_t in line 10. Many of the same types of
> errors occur in xxx_fs.h where every filesystem under the sun is
> represented by the 'xxx'. The common thread to this problem seems to
> be the inclusion of <asm/uaccess.h>. Has something changed in this
> file? If so, any ideas how I can work around this?
>
> Thanks,
> Ed
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is that process a thread?
Date: Mon, 06 Nov 2000 23:18:09 -0000
On Mon, 06 Nov 2000 20:35:49 GMT George MacDonald <[EMAIL PROTECTED]> wrote:
| Maciej Golebiewski wrote:
|>
|> George MacDonald wrote:
|> >
|> > Is there an easy way to figure out if a process is a thread? I'm thinking
|> > about adding a new visual representation for threads in treeps. i.e.
|> >
|> > http://www.slip.net/~gmd/tps/treeps.htm
|> >
|> > but need a quick way to figure out if an entry in /proc is a thread.
|>
|> I think that the only way to check if two two entries in /proc are two threads
|> of the same process is to verify that they share the same address space. But
|> I'm not sure if there is enough information in /proc to do it... Maybe not.
|>
|> 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?
What is initially a thread can become a non-thread by remapping its address
space on it's own. That may not be what threads are supposed to be able to
do, but a process can do that. It could be argued that a thread should be
able to do this anyway.
How much of the address has to overlap to be a thread? 100%? Does each thread
really need access to another thread's stack (probably yes, though I could also
argue that was be bad and possibly dangerous practice).
The point is, we look at threads in black and white, but in fact the reality
is that things are really very gray. We need to be prepared to deal with all
of that.
| 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...
How about a showing of how much address space is shared between them?
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Re: Porting driver source from 2.2.14 to 2.2.16
Date: Mon, 06 Nov 2000 23:49:24 GMT
Hello Ed,
I just tripped over something similar compiling a simple user-land
program (that exercises my device driver) under 2.2.14-5.0. For some
reason, __KERNEL_STRICT_NAMES is defined (as seen by linux/types.h)
which leaves me w/uint32_t undefined. I suspect that this also leaves
time_t undefined, which would cause the parse error messages.
I haven't figured out yet why __KERNEL_STRICT_NAMES is defined, or
whether it should be (or what it means). Perhaps someone else can
reflect on this?
Sorry to be so vague. I only throw this out there in hopes it will
shorten your search for a solution (and mine).
Yours,
Bill
--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
In article
<[EMAIL PROTECTED]>,
Ed Hudson <[EMAIL PROTECTED]> wrote:
> I have written a kernel module that builds and runs fine under kernel
> 2.2.14 and also was tested on 2.0.33. I have found that when I try to
> build it under 2.2.16 and 2.2.17 I get a nearly endless stream of
> errors. One that seems to appear quite frequently is in time.h... a
> parse error before time_t in line 10. Many of the same types of
> errors occur in xxx_fs.h where every filesystem under the sun is
> represented by the 'xxx'. The common thread to this problem seems to
> be the inclusion of <asm/uaccess.h>. Has something changed in this
> file? If so, any ideas how I can work around this?
>
> Thanks,
>
> Ed
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: Is that process a thread?
Date: 6 Nov 2000 19:26:03 -0500
In article <[EMAIL PROTECTED]>,
George MacDonald <[EMAIL PROTECTED]> wrote:
>
>Perhaps /proc/#pid/threads/#tid/...
>
>Then one could peer into the individual threads. Could a kernel module do
>this?
Thread == process. There is no such thing as "process containing this thread"
- there are "other processes that may share something with this process".
E.g. address space. Moreover, PIDs are unique (as they should be).
It is not Solaris. There is no distinction between the process and LWP.
Threads are not parts of processes.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: HOWTO: Redhat Kernel Customization mini-HOWTO
Date: Mon, 06 Nov 2000 17:55:36 -0800
Redhat Kernel Customization mini-HOWTO
by Kaelin Colclasure <[EMAIL PROTECTED]>
Version 2000.11.04
(Please email corrections, feedback, etc. to the author.)
There are a couple of extra steps necessary when rebuilding your
kernel from sources on a Redhat system. These notes were made while
building a stripped-down smp kernel for Redhat 7.0 from the
kernel-2.2.17-4.src.rpm from rawhide.
First, build the kernel Redhat's way -- from the source RPM. Install
it following Redhat's standard procedure:
[Commands shown here assume the kernel version is 2.2.17-4smp]
1) Do the 'rpm -Uvh kernel-*' thing...
2) Run '/sbin/mkinitrd /boot/initrd-2.2.17-4smp.img 2.2.17-4smp'
3) Edit /etc/lilo.conf to point to the new kernel and image
4) Run '/sbin/lilo -v' to update the boot sector on your HDD(!)
5) Take a deep breath, cross your fingers and reboot...
If all goes well, you'll have a running version of the latest kernel
sources with Redhat's stock configuration. You'll also have a kernel
source tree in /usr/src/linux that you can work with from this point
forward -- leave the stuff in /usr/src/redhat/BUILD alone!
It's important to note that the kernel source tree does not actually
correspond to the kernel you're running at this point *unless* you
happen to be using the "stock" (e.g. non-smp, non-enterprise) Redhat
kernel. And even if you are, the following step are probably a good
idea just to be sure...
To prepare for building your customized kernel, you need to configure
your kernel sources to match what you have running. If you look in the
configs subdirectory, you should find several configuration files with
names like "kernel-2.2.17-i686-smp.config". Find the one that matches
the Redhat kernel you're running and remember its name. Then do the
following steps:
1) Run 'make mrproper'
2) Edit the EXTRAVERSION definition in the Makefile to be something
different than your running kernel.
[If you fail to do this, 'make modules_install' will overwrite
the modules for your running kernel with the modules for the
kernel you're building. That's... not good. If you do this, you
probably have to boot from some *other* kernel image to recover.]
3) Run 'make menuconfig' and use the option (at the bottom of the
menu) to load the kernel configuration from the config file
located above.
4) Save this as your kernel configuration (If you're feeling cockey
by now, you can of course edit the configuration at this point)
5) Run 'make dep'
6) Run 'make bzImage'
7) Run 'make modules'
8) Run 'make modules_install'
9) Run 'make bzlilo'
Note that that last step does *not* prepare the new kernel for booting
on a Redhat system. It should leave two new files in your root
directory:
-rw-rw-r-- 1 root root 214022 Nov 4 19:28 System.map
-rw-rw-r-- 1 root root 660478 Nov 4 19:28 vmlinuz
Historically, lilo was typically configured to point to a kernel image
at this location -- but large cheap HDDs have mostly eliminated this
practice. Redhat has a /boot directory that should have a separate
partition mounted under it. That partition must be completely
contained within the first 1024 cylinders of the boot device or lilo
might not be able to boot from a kernel image stored there!
For these next few steps, we'll pretend you named your new kernel
2.2.17-4smp-klc (no doubt in tribute to your humble author). Replace
as appropriate below:
1) Move /vmlinuz to /boot/vmlinuz-2.2.17-4smp-klc
2) Move /System.map to /boot/System.map-2.2.17-4smp-klc
3) Copy /usr/src/linux/vmlinux to /boot/vmlinux-2.2.17-4smp-klc
[Note: I don't know why -- the kernel documentation I could find
says vmlinux is just an intermediate file -- but Redhat seems to
put a copy in /boot]
4) Copy /boot/module-info to /boot/module-info-2.2.17-4smp-klc
[Note: Again, no clue here -- but Redhat seems to do something
with module-info and omitting it seems like a bad idea...]
5) Run '/sbin/mkinitrd /boot/initrd-2.2.17-4smp-klc.img
2.2.17-4smp-klc'
6) Edit /etc/lilo.conf to point to the new kernel and image
7) Run '/sbin/lilo -v' to update the boot sector on your HDD(!)
8) Take a *really* deep breath, cross your fingers and reboot...
Now, during this first reboot you may see some modules fail to load
because of a missing /lib/modules/2.2.17-4smp-klc/modules.dep file.
[This may even cause the hardware auto-detection support to warn you
that a device has been removed from your system -- and offer to remove
the supporting configuration data. If this happens, you want to say
no.] Take heart -- this gets created automatically by depmod(8)
sometime later in the boot process. Subsequent reboots should load all
modules without a hitch.
Astute observers will notice that there are a few symbolic links in
the /boot directory that point to kernel-version-specific names.
AFAICT none of these need be touched if you're simply customizing a
kernel from an existing Redhat RPM release. System.map gets updated
automatically during the boot process, and the rest either point to
files that remain the same for customized kernels or don't appear to
be used at all.
If something goes wrong, reboot your machine with an older, working
kernel image (you saved one, right?) and refer to "the usual sources"
for troubleshooting tips.
Happy hacking!!!
-- Kaelin
------------------------------
** 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
******************************
