Linux-Development-Sys Digest #396, Volume #8 Sun, 7 Jan 01 18:13:12 EST
Contents:
Re: Signals and threads in Linux (Kaelin Colclasure)
Re: NVIDIA-9.0-5 + kernel 2.4.0 (peter katzmann)
Re: Forcing a Core Dump ("Paul Pluzhnikov")
Re: GIve me a advice build enterprise linux system. (Kaelin Colclasure)
Re: Yamaha CDRW 4416E (Rob King)
Re: Generating core file ("Peter T. Breuer")
Re: Extending /proc filesystem on Solaris 7/8? ([EMAIL PROTECTED])
Re: Extending /proc filesystem on Solaris 7/8? (Kaelin Colclasure)
Program (or program) that uses LSF (Jens)
Linux OS for the Apple Mac
Re: Extending /proc filesystem on Solaris 7/8? (Joerg Schilling)
----------------------------------------------------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: Signals and threads in Linux
Date: 07 Jan 2001 10:42:41 -0800
Andi Kleen <[EMAIL PROTECTED]> writes:
> Kaelin Colclasure <[EMAIL PROTECTED]> writes:
>
> > How do POSIX signals interact with threads under Linux? Since each
> > thread in a process has its own pid, does it have its own signal mask
> > and sigaction set too? Or do all of the pids somehow share this state?
>
> Each thread has an own signal mask/queue, but the handlers are normally shared
> (when CLONE_SIGHAND is set, which LinuxThreads does)
Aha, that makes sense. In fact, the clone man page clarifies several
issues for me. Thanks for the pointer.
> > In general, I am assuming that a signal sent to a specific pid is
> > delivered to that pid -- regardless if it's the main thread of a
> > process or not.
>
> That's ok on LinuxThreads, but it's non portable.
I'm not relying on this behavior -- just trying to get straight in my
own head how the thread / pid correlation behaves on Linux.
-- Kaelin
------------------------------
From: peter katzmann <[EMAIL PROTECTED]>
Subject: Re: NVIDIA-9.0-5 + kernel 2.4.0
Date: Sun, 07 Jan 2001 15:12:37 +0100
Reply-To: [EMAIL PROTECTED]
fszuper wrote:
>
> arg, i try to build a new driver for use with the release 2.4.0 of the
> kernel
>
> it say me :
>
> [root@XIII-MAIN NVIDIA_kernel-0.9-5]# make all
>
> rm -f nv.o os-interface.o os-registry.o Module-linux NVdriver
>
> cc -c -Wall -Wunknown-pragmas -Wno-multichar -O -D__KERNEL__ -DMODULE -D_LOO
> SE_KERNEL_NAMES -DUNIX -DLINUX -DNV4_HW -DNTRM -DRM20 -D_X86_=1 -Di386=1 -D_
> GNU_SOURCE -DRM_HEAPMGR -D_LOOSE_KERNEL_NAMES -I. -I/usr/src/linux/include
> nv.c
>
> In file included from nv.c:52:
>
> nv.h:131:6: warning: #warning This driver is not officially supported on
> post-2.2 kernelsnv.c: In function `nv_lock_pages':
>
> what's the problem?
Did you read it, this driver is not supported with kernels greater the
the 2.2.X release.
Make a quick deja search in this newsgroup and you find the appropriate
help what to do to get it run.
peter
------------------------------
From: "Paul Pluzhnikov" <[EMAIL PROTECTED]>
Subject: Re: Forcing a Core Dump
Date: Sun, 07 Jan 2001 18:54:20 GMT
"Marc Schneider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have a bug which is difficult to debug. I am getting intermitted
> Segmentation Fault in my program. If I run the program in a debugger, it
> doesn't segfault. I would like to force my program to dump core for all
> segfaults. Is there an easy way to do this?
>
Your program most likely *already* dumps core *every* time
it encounteres a segmentation fault (that is the default).
It does not, however, encounter the condition that causes segfault, when run
under debugger.
Make sure you run the program in the same environment and with the same
arguments when you run it under debugger.
If segfault still does not occur, you have several options:
- do post-mortem analysis:
gdb exename core
(gdb) where
- utilize one of the memory-checking tools:
mpatrol, efence, Insure++
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: GIve me a advice build enterprise linux system.
Date: 07 Jan 2001 10:53:40 -0800
"junwon,Seo" <[EMAIL PROTECTED]> writes:
> Hi.
> I have to build linux system.
>
> Suppose that..
> I have 10 TB NAS Storage, and 10 linux machine.
>
> My puppose that each linux machine mount over network 10TB storage to local
> mount point(ex. /home)
> Maybe using NFS ...
> Is possible?
>
> And, I heard that ext2 fs's maximum file system is 4TB.
> Well then, How much ReiserFS's maximum file system size?
> And ReiserFS over the NFS is reliable?
Well, if by NAS you mean "network-attached storage", then ext2's
limitations are irrelevant. Your Linux machines will simply see a
large NFS volume. AFAIK NFS does not impose any limitations on the
size of an exported volume (but I could be wrong).
What filesystem is used on the NAS appliance is the vendor's problem.
Indeed, it's unlikely you could change it even if you wanted to.
-- Kaelin
------------------------------
From: Rob King <[EMAIL PROTECTED]>
Subject: Re: Yamaha CDRW 4416E
Date: Sun, 07 Jan 2001 14:02:53 -0500
Sadly it doesn't read any sort of cd's, it just hasn't read anything, and i
haven't checked those yet, but thanks for the help
Kasper Dupont wrote:
> Rob King wrote:
> >
> > Hi i have this burner as my secondary ide slave with a pioneer 16x
> > dvd-rom as it's primary, and when i boot in linux, the burner won't read
> > anything, i would like to now, if this is a problem with my system, or
> > if it is uncommon.
>
> It definitely should work, what happens when you try to read
> something? What messages does the kernel write when detecting
> IDE units at bootup. Look in /var/log/messages.
>
> --
> Kasper Dupont
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: Generating core file
Date: Sun, 7 Jan 2001 21:08:27 +0100
Gene Chang <[EMAIL PROTECTED]> wrote:
> I am writing an application which uses a shared library(.so). My problem is
> this:
> If my application has a default, it will create a core file.
I think you mean "a fault", but never mind ...
> If the segfault is in the shared lib, I only get a Segmentation fault
> message but not core dump.
That's weird. I suppose it's always possible that the shlib code
installed its own signal handler, but other than that I know of no
reason why that should happen. Try making your own .so.
> Anybody has an idea why? I have the source code and build environment for
No idea. Helpful, eh!
Peter
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: Sun, 07 Jan 2001 21:16:32 -0000
In comp.unix.solaris and comp.os.linux.development.system Kaelin Colclasure
<[EMAIL PROTECTED]> wrote:
| [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer) writes:
|
|> Kaelin Colclasure <[EMAIL PROTECTED]> writes:
|>
|> >I've developed a kernel module under Linux that I'd like to port to Solaris.
|> >Unfortunately, it looks like Solaris' /proc filesystem is not extensible
|> >the way Linux's is... At least, I could find no mention of how to extend
|> >it in Sun's "Writing Device Drivers" book for Solaris 8.
|>
|> The Solaris /proc filesystem is not a dumping ground for non-process
|> related information.
|>
|> Is your kernel module adding information to each process?
|>
|> If not, the information has no business in /proc.
|
| Ah, I see. Well, for better or for worse, the /proc filesystem on Linux
| *is* a bit of "a dumping ground". :-)
Relating the name "/proc" to what is there, certain that description would
seem to be fitting. However, there is legitimate value to having a file
like hierarchy for exchange of information between the kernel and processes.
There are many things, many of which have multiple instances, which should
appears there. Process information is just one of them. It happens to be
the classic one, and where the name comes from.
But the name is a bad choice.
I hope that the attitude of not allowing "other stuff" in /proc in
Solaris is only from the point of view of name purity, and that some
other name would be preferred. Maybe /kern? I would most certainly
hate to see Solaris limited by people who carry around the attitude
that new ideas can't be used because things have worked well for them
the way it has always been. Of course that may be part of the reason
I have to go download and install tons of extra stuff after doing a
Solaris install, because Solaris is still rather far behind in some
areas (certainly not in all areas).
There are lots of people I label as "old timey traditionalists" who
tend to resist progress. I just got this sense when I first read the
remarks that "here is yet another one" for Solaris (which has plenty
as it is). Were it not for the semantics of the name "/proc" I might
have to come to that very conclusion.
What would be a good idea, I think, is to re-examine what it is that
needs to be done with regard to information exchange between the kernel
and its processes, and how that information should be presented. Then
choose the names, and do it. Should it be a filesystem access much like
/proc has now? Or should it be entirely in system calls? Or both?
As linux now gets a kernel based devices filesystem (/devfs), it and
Solaris are coming into new meeting grounds (with differences). What
will be the next step in Solaris? Will it ever get something like the
extra "dumping ground" Linux has (but presumably with a different name)?
| My decision to use /proc vs. /dev on Linux was largely driven by my desire
| that the module be self-configuring when dynamically loaded. E.g. you
| load the kernel module and the /proc/tnf tree springs into existance,
| configured exactly to match the module's compile-time configuration. And
| when you unload the module from the Linux kernel, the /proc entries go
| away leaving no dangling special file entries in the host file system.
The dynamic is one of the advntages Linux's /proc has. OTOH, Solaris
does have /devices. Could it go there? And Linux 2.4 now has /devfs.
| There was also the factor that the /dev directory is (traditionally) a
| flat namespace, while the entries I need to place in the file system
| have a natural hierarchy. E.g. each trace resource requires 1 + ncpus
| filesystem entries.
|
| I believe that the new devfs work ongoing in the latest Linux kernels
| may address the former point. I'm not sure about the latter... I'm
| crossposting this article to c.o.l.d.s so maybe someone will enlighten
| me. But for the moment it's a moot point since I need to work with
| 2.2.x kernels...
I'll be curious if either kernel based device namespace can be used for
these kinds of purposes.
| I take it, Casper, that your recommendation would be to stick with the
| traditional /dev entries on Solaris? Forgive my ignorance -- I just got
| my Solaris reference material from Fatbrain yesterday -- but is there
| a way to dynamically create /dev entries at module load time on Solaris?
| Short of augmenting the load process with a script?
See if he would rule out the /devices namespace. I don't know if that
could even work, but hopefully so. Then why not /devfs in Linux, too?
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: 07 Jan 2001 14:22:23 -0800
[EMAIL PROTECTED] writes:
[...]
> I hope that the attitude of not allowing "other stuff" in /proc in
> Solaris is only from the point of view of name purity, and that some
> other name would be preferred. Maybe /kern? I would most certainly
> hate to see Solaris limited by people who carry around the attitude
> that new ideas can't be used because things have worked well for them
> the way it has always been. Of course that may be part of the reason
> I have to go download and install tons of extra stuff after doing a
> Solaris install, because Solaris is still rather far behind in some
> areas (certainly not in all areas).
I don't think the Solaris folks are luddites or anything -- the POV
that namespace pollution is to be avoided is certainly valid. I agree
that, as it's used on Linux today, /proc is a poor name choice.
And as for the "tons of extra stuff" you install, I'm going to guess
that a lot of it is GNU software that's under the GPL. Remember, the
Solaris folks are still saddled by the legal restrictions imposed by
their corporate cathederal. They do seem to be working on that. :-)
[...]
> What would be a good idea, I think, is to re-examine what it is that
> needs to be done with regard to information exchange between the kernel
> and its processes, and how that information should be presented. Then
> choose the names, and do it. Should it be a filesystem access much like
> /proc has now? Or should it be entirely in system calls? Or both?
> As linux now gets a kernel based devices filesystem (/devfs), it and
> Solaris are coming into new meeting grounds (with differences). What
> will be the next step in Solaris? Will it ever get something like the
> extra "dumping ground" Linux has (but presumably with a different name)?
Well in my book, the filesystem approach is a clear win over new system
calls. It may be crufty, but it gets the job done! Makes me want to
spend a few months really checking out Plan 9...
> | My decision to use /proc vs. /dev on Linux was largely driven by my desire
> | that the module be self-configuring when dynamically loaded. E.g. you
> | load the kernel module and the /proc/tnf tree springs into existance,
> | configured exactly to match the module's compile-time configuration. And
> | when you unload the module from the Linux kernel, the /proc entries go
> | away leaving no dangling special file entries in the host file system.
>
> The dynamic is one of the advntages Linux's /proc has. OTOH, Solaris
> does have /devices. Could it go there? And Linux 2.4 now has /devfs.
/devices does appear to be a possibility.
> | There was also the factor that the /dev directory is (traditionally) a
> | flat namespace, while the entries I need to place in the file system
> | have a natural hierarchy. E.g. each trace resource requires 1 + ncpus
> | filesystem entries.
> |
> | I believe that the new devfs work ongoing in the latest Linux kernels
> | may address the former point. I'm not sure about the latter... I'm
> | crossposting this article to c.o.l.d.s so maybe someone will enlighten
> | me. But for the moment it's a moot point since I need to work with
> | 2.2.x kernels...
>
> I'll be curious if either kernel based device namespace can be used for
> these kinds of purposes.
Well, apart from the funkey naming conventions, /devices on Solaris
appears to fill the bill. It supports hierarchies, is all dynamic
entries, etc.
I have yet to see the new Linux devfs. But, even if it's not in the
initial release, I'm sure it's do-able. :-)
>
> | I take it, Casper, that your recommendation would be to stick with the
> | traditional /dev entries on Solaris? Forgive my ignorance -- I just got
> | my Solaris reference material from Fatbrain yesterday -- but is there
> | a way to dynamically create /dev entries at module load time on Solaris?
> | Short of augmenting the load process with a script?
>
> See if he would rule out the /devices namespace. I don't know if that
> could even work, but hopefully so. Then why not /devfs in Linux, too?
The immediate problem with Linux's devfs is that 2.2.x kernels don't
support it, and I do need to support 2.2.x kernels. :-/
-- Kaelin
------------------------------
From: Jens <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Program (or program) that uses LSF
Date: Sun, 07 Jan 2001 22:40:23 +0000
Hi
Can anyone point me to a program (or example) that uses LSF (Linux Socket
Filtering)?
Thanks,
Jens
[EMAIL PROTECTED]
------------------------------
From: <[EMAIL PROTECTED]>
Crossposted-To: alt.linux
Subject: Linux OS for the Apple Mac
Date: Sun, 7 Jan 2001 22:59:03 -0000
Hi all,
I would like to install a version of Linux on my
Macintosh Performa
Spec:
MC68030 32bit processor
8mb RAM
Interfaces : ADB port
2 RS-232/RS-422 serial ports
SCSI interface
Any ideas as to which version of Linux would be the best. It only has a
3.5 floppy disk drive
Thanks for the help !
------------------------------
From: [EMAIL PROTECTED] (Joerg Schilling)
Crossposted-To: comp.unix.solaris
Subject: Re: Extending /proc filesystem on Solaris 7/8?
Date: 7 Jan 2001 23:08:59 GMT
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>|> Is your kernel module adding information to each process?
>|>
>|> If not, the information has no business in /proc.
>|
>| Ah, I see. Well, for better or for worse, the /proc filesystem on Linux
>| *is* a bit of "a dumping ground". :-)
>
>Relating the name "/proc" to what is there, certain that description would
>seem to be fitting. However, there is legitimate value to having a file
>like hierarchy for exchange of information between the kernel and processes.
>There are many things, many of which have multiple instances, which should
>appears there. Process information is just one of them. It happens to be
>the classic one, and where the name comes from.
>
>But the name is a bad choice.
>
>I hope that the attitude of not allowing "other stuff" in /proc in
>Solaris is only from the point of view of name purity, and that some
>other name would be preferred. Maybe /kern? I would most certainly
It is no attitude bu simply the attempt to keep Solaris clean.
/kern or /sys would ne the right place for such additions.
>hate to see Solaris limited by people who carry around the attitude
>that new ideas can't be used because things have worked well for them
>the way it has always been. Of course that may be part of the reason
>I have to go download and install tons of extra stuff after doing a
>Solaris install, because Solaris is still rather far behind in some
>areas (certainly not in all areas).
Do you really believe that the additions in Linux /proc are new?
It is an idea that goes back to plan 9 as /proc does too.
>There are lots of people I label as "old timey traditionalists" who
>tend to resist progress. I just got this sense when I first read the
>remarks that "here is yet another one" for Solaris (which has plenty
>as it is). Were it not for the semantics of the name "/proc" I might
>have to come to that very conclusion.
Well it looks rather the other way round. Many of the things you believe
are new on Linux have been invented by plan 9 guys or by Sun.
If someone likes to add functionality in files he could just
write a filesystem for this purpose.
>| My decision to use /proc vs. /dev on Linux was largely driven by my desire
>| that the module be self-configuring when dynamically loaded. E.g. you
>| load the kernel module and the /proc/tnf tree springs into existance,
>| configured exactly to match the module's compile-time configuration. And
>| when you unload the module from the Linux kernel, the /proc entries go
>| away leaving no dangling special file entries in the host file system.
>
>The dynamic is one of the advntages Linux's /proc has. OTOH, Solaris
>does have /devices. Could it go there? And Linux 2.4 now has /devfs.
NO, /devices is definitely the wrong place. It is only for
dynamic nodes referring to drivers.
--
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
