Linux-Development-Sys Digest #664, Volume #7 Wed, 8 Mar 00 21:13:20 EST
Contents:
Re: Why a file system ? (David Fox)
Re: Why a file system ? (David Fox)
Re: Swapping HDs... how best to do it? (Don Waugaman)
Re: Why a file system ? (David Fox)
Re: Questions on kernel code (Jon Becker)
Re: Segmentation fault with init (sysVinit) (Juergen Heinzl)
Re: writing a module to implement a firewall (Florian Heinz)
Re: Odd cua0 vs. ttyS0 bug from gpm w/kernel 2.2.14 (m buller)
Re: Impasse with 2 SCSI controllers, kernel mods required? (teri)
Re: Questions on kernel code (Kaz Kylheku)
Re: Impasse with 2 SCSI controllers, kernel mods required? (teri)
Re: Questions on kernel code (Kaz Kylheku)
----------------------------------------------------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Subject: Re: Why a file system ?
Date: 08 Mar 2000 16:17:24 -0800
"Peter T. Breuer" <[EMAIL PROTECTED]> writes:
> d wrote:
> : You are right, a database would be a big improvement over the current
> : organization. Consider that in a Unix heirarchical file system each
> : file is identified by a pathname. In database parlance, this is an
> : ordered collection of boolean attributes. In a system designed in the
> : `database style' those attributes would be unordered, and the file
>
> : /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/cc1
>
> : would be the same file as
>
> : /gcc-lib/egcs-2.91.66/lib/i386-redhat-linux/usr/cc1
>
> Well, one is its primary key, and the other is a secondary key or
> perhaps a query. There is nothing to stop you changing "cd" to something
> which looks up all possible perms of the path components. Of course,
> you have to change mkdir, too, to stop ypu making two distinct
> directories with overlapping sets of components.
This would be a mistake.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Subject: Re: Why a file system ?
Date: 08 Mar 2000 16:21:06 -0800
[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <[EMAIL PROTECTED]>,
> David Fox <d s f o x @ c o g s c i . u c s d . e d u> wrote:
> >as well as all other permutations of pathnames. Now what is the
> >significance of having each ordering of these attributes refer to a
> >distinct set of files? Well, none that I can think of, except to
> >cause confusion.
>
> IOW, you can't think...
Then perhaps you should GFY.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: Swapping HDs... how best to do it?
Date: 8 Mar 2000 17:12:58 -0700
In article <[EMAIL PROTECTED]>,
Paul D. Smith <[EMAIL PROTECTED]> wrote:
>So... I have this crusty old 2G drive that contains all my Linux
>partitions.
>It's getting stuffy on there, and really, HD space is _so_ cheap, so I
>went out and got a new 15G HD.
>Now I want to put my current Linux install on the new disk and get rid
>of the old one (it's 4 years old or so, and I don't really have the
>slots to keep it around anyway).
[ deletia ]
>So. Anyone have hints as to how to move an entire distro from one disk
>to another? Can I just partition the new disk, then dd the old
>partitions, even though the new ones are going to be larger? I didn't
>think you could do that...
>I'm really mainly concerned about the root partition; everything else is
>just normal files and tar should move 'em without trouble (am I missing
>anything?).
>For example I worry that tar won't copy things like the /dev files
>correctly, even if I booted into a single-user mode where /proc didn't
>exist (or used some other method to avoid tar'ing it).
Tar will work on device files.
>One thought I had was to create a Linux install on the new disk using
>my Debian 2.1 disks, then copy all the "basics" (everything but /dev and
>/proc?) with tar to update the system. Seems a bit dangerous though.
>
>Other ideas? Am I missing something?
Try GNU parted - I think it's up to version 1.10, and there's probably a
.deb for it (not sure, but there is an RPM).
I recently upgraded my main machine to a new 10G drive from an old 6G
drive - parted copied all the partitions onto the new drive perfectly.
I put the old drive in a different machine and copied its older disk to
the 6G drive, and that worked fine - DOS and Win95 FAT16 & FAT32 partitions
copied perfectly, too, even when being resized.
Highly recommended.
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
I don't believe in a no-win scenario. - Kirk, _The Wrath of Khan_
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Subject: Re: Why a file system ?
Date: 08 Mar 2000 16:35:13 -0800
"Peter T. Breuer" <[EMAIL PROTECTED]> writes:
> d wrote:
> : You are right, a database would be a big improvement over the current
> : organization. Consider that in a Unix heirarchical file system each
> : file is identified by a pathname. In database parlance, this is an
> : ordered collection of boolean attributes. In a system designed in the
> : `database style' those attributes would be unordered, and the file
>
> : /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/cc1
>
> : would be the same file as
>
> : /gcc-lib/egcs-2.91.66/lib/i386-redhat-linux/usr/cc1
>
> Well, one is its primary key, and the other is a secondary key or
> perhaps a query.
Yes, this is an accurate description of how things work now. My point
is that on the balance we would be better off if the order of the path
elements was not significant. If anyone is interested in going into
this topic beyond the level of superficial insult, I invite them to
suggest a real-world situation where a heirarchical file system has
advantages over a relational file system.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: [EMAIL PROTECTED] (Jon Becker)
Subject: Re: Questions on kernel code
Date: 9 Mar 2000 00:35:25 GMT
In article <8a6jiv$[EMAIL PROTECTED]>,
Alexander Viro <[EMAIL PROTECTED]> wrote:
>In article <8a6hkf$e4r$[EMAIL PROTECTED]>,
>Jon Becker <[EMAIL PROTECTED]> wrote:
>
>>So if a timer interrupt comes in, then it will be handled, which among
>>other things activates the TIMER_BH bottom half. That bottom half
>>will then be run, which sets the current task's need_resched flag if
>>its quantum has expired. Then it'll go to ret_from_intr. Why does
>>this not result in schedule() being called?
>
>It does. However, at that moment you are not within the interrupt - you
>are in the glue, heading out of the kernel. The critical thing about
>schedule() is that _all_ code in the upper half is guaranteed that no context
>switches will happen unless we explicitly ask for them. Control may be
>taken out (interrupt may happen and bottom half code will be executed),
>but it will return to the same process. If you are heading to the user
>mode - that's it, we can call schedule() without breaking this warranty.
Ah, by the time bottom-half handling has finished, in_interrupt()
is no longer true? Okay, so when the comment I mentioned says that
the scheduler can't be called from an interrupt, what it really
meant was that it can't be called from an interrupt if the current
task was in kernel mode before the interrupt (which is all that
matters in that particular case anyway).
Thanks for the response.
-Jon
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Segmentation fault with init (sysVinit)
Date: Thu, 09 Mar 2000 00:42:28 GMT
In article <[EMAIL PROTECTED]>, Sebastien Dessimoz wrote:
>Hi,
>
>I am trying to do my own fileystem and kernel. First I have compiled my
>kernel (2.2-10) and everything works fine. Then I have done a filesystem
>and I managed to boot correctly the OS if the kernel does
>execve("/bin/sh") at the end of its initialization.
>
>My next goal was to launch the famous init program from the sysVinit
>package. I took init and compiled it without any problem. However, when
>I try to boot, just after the kernel does a execve(/sbin/init) nothing
>happens... I do not see any message (even not Init v.2.8.xx). To correct
>that I have checked if my filesystem has all the necessary libraries
>(with ldd) and it seems to be OK. The most interesting point is that if
>I boot with the shell instead of init, I have tried then to launch init.
>The result is that it makes a Segmentation Fault.
>
>I did a deeper investigation then. I booted with my standard Linux
>Redhat 6.1 distribution. Then I mounted the famous filesystem (which is
>on one of my other disks). If I call the init (with ./init in order no
>to call the general init), it works.
>However, if I use "chroot /mnt/test /sbin/init", it makes again a
>segmentation fault. I wanted to debug, but it was for me too difficult
>because of this chroot call.
>
>Can somebody help me?
I should admit it is late here, so lacking some ideas but you might
start with a static version of init to exclude library problems.
Since chroot /mnt/test /sbin/init is failing a strace -f might reveal
more. Make sure there is a /dev and a /proc directory on /mnt
available too and esp. a *valid* /dev. E.g. if /mnt/bin/sh is a static
binary there is no need to map shared libraries for this binary. Older
libs / dynamic linkers required /dev/zero for instance.
As sysvinit never died on me in all those years no concrete hints,
sorry, but perhaps someone else.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Florian Heinz <[EMAIL PROTECTED]>
Subject: Re: writing a module to implement a firewall
Date: Thu, 09 Mar 2000 01:33:02 +0100
Reply-To: [EMAIL PROTECTED]
> Hi
> i am trying to write some sort of a packet filter/firewall for linux.
> I am running RH6.1
> i have tried doing so using dev_add_pack and register my handling
> function.
> I do get the chance to see both incoming and outgoing packets,
> however, i can only alter incoming packets.
> looking at the kernel source showed me that the packet i get on the
> incoming side (sent to me by dev_queue_xmit_nit) are only a clone, and
> i have no way of returning an answer about any changes i have made to
> the packet.
> can any help me take control over outgoing packets ?
Have a look at register_firewall();
reading linux/include/linux/firewall.h helps too...
If you need an example, I can point you to the sinus-firewall,
www.ifi.unizh.ch/ikm/SINUS/firewall/
download version 0.1.5 and look at server/sf_device.c, in which the
firewall-functions are registered
hth
------------------------------
From: m buller <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Odd cua0 vs. ttyS0 bug from gpm w/kernel 2.2.14
Date: Thu, 09 Mar 2000 00:30:20 GMT
Hi Peter,
Thanks for the info. You are correct. The major # for the Digi ports
ttyD0-ttyD16 are at 22, the same as cud0-cud31. The funny thing is the rest
of the defined ports (as created by the digi rpm install) are at major 23.
Also the creation date for D0-D16 is April 17, 1999, for D17-D31 and cud0 -
cud31 is March 5, 2000 the date of my digi rpm install. It appears that the
digi install program works correctly but there are predefined (by redhat ?)
ttyD0-ttyD17 devices that do not get over written. Now I need to find out
about device creation. Is it safe to just delete ttyD0-ttyD17 and use
mknod to recreate them? Or is there more to it then that ? Know of any good
howto's ?
Thanks again
H. Peter Anvin wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author: m buller <[EMAIL PROTECTED]>
> In newsgroup: comp.os.linux.development.system
> >
> > I checked the version of getty (getty_ps 2.0.7j-7) looks like it is the
> > latest. I contacted Digi tech support they suggested I try deleting
> > cud0. I did this, but still get the same message. Note the port (dev)
ttyD0
> > works fine.
> >
> > Any Ideas ?
> >
>
> You probably have the majors on /dev/cud* and /dev/ttyD* reversed.
> Digiboard have had problems with it... at least some versions of the
> drivers put the smaller major as /dev/cud*, which violates the
> invariant that you find the callout device by adding 1 to the major of
> the callin one.
>
> -hpa
> --
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: [EMAIL PROTECTED] (teri)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.setup,alt.os.linux.caldera
Subject: Re: Impasse with 2 SCSI controllers, kernel mods required?
Date: Wed, 8 Mar 2000 20:01:20 EST
In article <[EMAIL PROTECTED]>,
John Belew <[EMAIL PROTECTED]> wrote:
>I have a similar problem (Adaptec 7880 and 2940UW adapters) with a
>RedHat 6.1 installation.
>
>RedHat describes the problem at:
>
> http://www.redhat.com/support/docs/gotchas/6.1/gotchas-6.1-6.html#ss6.27
>
>with the words
>
> Systems with multiple SCSI cards will find that the SCSI modules
> have been loaded in the opposite order than specified. This can
> cause drives letters to change due to Linux's SCSI way of dealing
> with drives.
>
>but I followed their suggested fix, without solving the problem.
Well, considering that their suggestion is a fixed RPM package and I'm
not running RedHat, I think I won't risk damaging my system, in an area
as critical as the boot process with non-caldera packages.
Furthermore, I have to point out that the boot order problem I see is when
both drivers (the 2940UW with the boot drive attached to it, and the 1542CF
that only has a scanner on it) are *compiled into the kernel*.
In this case the kernel repeatedly tries to acces disk 0 on the wrong
controller, and prints plenty of messages while doing so. This is with
a freshly compiled 2.2.14.
When I try to load the 1542CF driver is when I get the device busy error.
When the 1542CF driver is loaded (as a module) at boot time the boot
process locks up, but there are no messages indicating that the kernel
is doing anything. This is with caldera's kernel (2.2.10)
Anyway, thanks for taking the time to respond.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Questions on kernel code
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Mar 2000 01:31:21 GMT
On 8 Mar 2000 21:44:47 GMT, Jon Becker <[EMAIL PROTECTED]> wrote:
>2) There is a comment in sched.c which indicates that the scheduler
>cannot be called at interrupt time. And indeed one of the first
>things done in schedule() is to check and make sure it's not running
>in an interrupt context. However, I have a problem with this for two
>reasons: first, I don't see how the code bears this out; second, if
Last I looked, it responds by triggering an exception by writing to a zero page
address. The error of calling the scheduler in an interrupt context is so
serious that the operating system cannot continue running.
>the scheduler cannot be called at interrupt time then I don't see how
>timesharing can be guaranteed.
You have to dig deeper. The scheduler can be called when returning from an
interrupt. An interrupt routine can set a preemption flag in the current task
context; the scheduler will the be invoked at some convenient time, when
the interrupt level is back to zero.
>As to the first, when an interrupt occurs it invokes a handler and
>then bottom halves are run. Then the code jumps to ret_from_intr
>(assuming the 386 version). This tests to see whether the code being
>returned to was in user mode when the interrupt came in. If so, it
>checks to see if the current task has its need_resched flag set. If
>so, it calls schedule().
There you go, you found it!
>So if a timer interrupt comes in, then it will be handled, which among
>other things activates the TIMER_BH bottom half. That bottom half
>will then be run, which sets the current task's need_resched flag if
>its quantum has expired. Then it'll go to ret_from_intr. Why does
>this not result in schedule() being called?
It must, if it is the outer most interrupt. Maybe you are tracing this wrong,
or are looking at cases when the execution of interrupt code is interrupted by
the timer. The scheduler can be called only when all cascaded interrupts pop
out.
>As for timesharing, if schedule can't be called at interrupt time,
>then it can only be done when the current task goes into kernel mode
>(right?).
That would result in user space tasks being cooperatively multitasked, which I
can assure you is not the case in Linux.
------------------------------
From: [EMAIL PROTECTED] (teri)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.setup,alt.os.linux.caldera
Subject: Re: Impasse with 2 SCSI controllers, kernel mods required?
Date: Wed, 8 Mar 2000 20:26:14 EST
In article <8a5oge$q41$[EMAIL PROTECTED]>,
Marc SCHAEFER <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.development.system teri <[EMAIL PROTECTED]> wrote:
>: Kernel recompile, this time with no 1542CF driver built-in. It is now
>: impossible to load the driver (Device or resource busy). I have read
>
>Any message issued by the dmesg command ? if it says something like
>`cannot allocate IRQ', reserve that IRQ in the PCI/PNP BIOS
>configuration as used by ISA/Legacy.
No. No messages at all related to the 1542CF or any failed loading
thereof. No "IRQ" messages either. I did a grep of all the
/var/log/messages* files as well as a careful examination and nothing
turned up. As I previously pointed out in the posting I referred to,
SCSISelect sees the 1542CF and the DMA test passes. There are no
IRQ, I/O or other resource conflict that I can see (the output of just
about all the /proc/* files was included in that posting)
My BIOS requires that PCI IRQs be reserved for PCI slots, given the
PCI cards I have. That's how I got the PCI cards to work, but there
is no such feature for the ISA bus. The other ISA card that has an
IRQ that's non-pnp (jumper) is the SMC ethernet card and I didn't have
to do anything in the BIOS for it to work perfectly. It's at IRQ 10.
The 1542CF is at IRQ 9 and nothing else is using it at the moment.
It used to be used by the PNP sound card without a problem. The sound
card is now using 15. In both cases it worked fine (it's being set up
by the commercial OSS driver)
One puzzling thing is that, in the case of both drivers being compiled
into the kernel, it would still insist on looking for the boot drive
on the wrong controller, even when that controller's BIOS is disabled.
Should it not ignore the controller whose BIOS is disabled for boot
purposes?
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Questions on kernel code
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Mar 2000 01:38:13 GMT
On 9 Mar 2000 00:35:25 GMT, Jon Becker <[EMAIL PROTECTED]> wrote:
>In article <8a6jiv$[EMAIL PROTECTED]>,
>Alexander Viro <[EMAIL PROTECTED]> wrote:
>>In article <8a6hkf$e4r$[EMAIL PROTECTED]>,
>>Jon Becker <[EMAIL PROTECTED]> wrote:
>>
>>>So if a timer interrupt comes in, then it will be handled, which among
>>>other things activates the TIMER_BH bottom half. That bottom half
>>>will then be run, which sets the current task's need_resched flag if
>>>its quantum has expired. Then it'll go to ret_from_intr. Why does
>>>this not result in schedule() being called?
>>
>>It does. However, at that moment you are not within the interrupt - you
>>are in the glue, heading out of the kernel. The critical thing about
>>schedule() is that _all_ code in the upper half is guaranteed that no context
>>switches will happen unless we explicitly ask for them. Control may be
>>taken out (interrupt may happen and bottom half code will be executed),
>>but it will return to the same process. If you are heading to the user
>>mode - that's it, we can call schedule() without breaking this warranty.
>
>Ah, by the time bottom-half handling has finished, in_interrupt()
>is no longer true? Okay, so when the comment I mentioned says that
Bottom half handling can run in the context of a process, or it can run
in the context of the outer-most interrupt (interrupt count 1).
When bottom half handling is invoked in process context, the interrupt
count is artificially incremented by 1. This ensures that bottom half
handling won't be re-entered from bottom half handling. It occupies a
private rung on the interrupt cascade ladder, so to speak.
(Or this is how it used to work in 2.0; there are some subtleties having
to do with SMP).
After bottom half handling finishes, the interrupt count eventually goes
to zero one way or another.
The fake increment of intr_count means that you are executing in
an *effective* interrupt context even if you are not.
>the scheduler can't be called from an interrupt, what it really
>meant was that it can't be called from an interrupt if the current
>task was in kernel mode before the interrupt (which is all that
>matters in that particular case anyway).
No, what it really means it that it can't be called if the interrupt
counter is zero. When an interrupt occurs, some instructions are
executed before this counter is bumped up, and after it is bumped
down again, some more instructions are executed. These other instructions
don't appear to be in an interrupt context any longer.
The rules don't apply to the interrupt glue code! The interrupt check in
schedule() is to guard against disastrous programming errors, whereby a
programmer mistakenly tries to suspend the execution in a non-task context.
For example, calling down() on a semaphore.
------------------------------
** 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
******************************
