Linux-Development-Sys Digest #779, Volume #8 Sat, 9 Jun 01 10:13:09 EDT
Contents:
why un*x does not support select/poll events on directories?
Re: why un*x does not support select/poll events on directories? (Alexander Viro)
Re: mmap+/dev/zero+madvise(WILLNEED) fails? (Zeljko Vrba)
System.map(or similiar file) in Solaris? (weining gu)
Re: how can I get a change to "official" linux? (found something new) (Eric Taylor)
Re: why un*x does not support select/poll events on directories?
Re: how can I get a change to "official" linux? (found something new) (John Reiser)
Re: why un*x does not support select/poll events on directories? (Alexander Viro)
Re: Matt Blaze's CFS on Linux - readdir problem. ("Binesh Bannerjee")
rh6.2 with shm of 1Gb? ("gdm")
while browsing severely encountering ZOMBIE and stucking up.. (v.nagasrinivas)
Porting from NetBSD to Linux ([EMAIL PROTECTED])
Type iso_t (Marcel Baur)
Re: Type iso_t (Marcel Baur)
winmodem source file can be modified ? ("Maximus Idius2")
----------------------------------------------------------------------------
From: <[EMAIL PROTECTED]>
Subject: why un*x does not support select/poll events on directories?
Date: 8 Jun 2001 15:02:44 GMT
if everything is a file why not unix designers add directory events to
select/poll system calls?
plese CC: your reply to [EMAIL PROTECTED]
any comment will be greatly appreciated
regards
Ulisses
Debian GNU/Linux: a dream come true
=============================================================================
"Computers are useless. They can only give answers." Pablo Picasso
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why un*x does not support select/poll events on directories?
Date: 8 Jun 2001 11:23:18 -0400
In article <9fqpek$2ge$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>
>if everything is a file why not unix designers add directory events to
>select/poll system calls?
Because select/poll is not a part of design, it's a hack added afterwards.
Broken one, at that.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (Zeljko Vrba)
Subject: Re: mmap+/dev/zero+madvise(WILLNEED) fails?
Date: 8 Jun 2001 15:56:55 GMT
Reply-To: [EMAIL PROTECTED]
On 7 Jun 2001 19:07:45 -0700, M. <[EMAIL PROTECTED]> wrote:
>
> Now that I am thinking more about this, is there a way to know if
> certain pages of the virtual address space of the process are in
> swap or in memory?
>
None that I know of (under Linux). Solaris has more featured /proc filesystem
and on Solarsi there may be a way..
------------------------------
From: weining gu <[EMAIL PROTECTED]>
Subject: System.map(or similiar file) in Solaris?
Date: Fri, 8 Jun 2001 11:25:54 -0500
Hi friends,
Does solaris have similiar file like System.map(in Linux)?
My research work needs to know all the symbol's address
in Solaris.
Many thanks.
Weining Gu
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: how can I get a change to "official" linux? (found something new)
Date: Fri, 08 Jun 2001 16:34:00 GMT
John Reiser wrote:
(re-orderd so you don't miss his 2nd point)
>
>
> Have you considered making the base address part of ulimit()?
> This would protect other processes from interference, yet provide
> an inheritable paramter for selected process trees.
I don't understand this, could you explain a bit what you mean
and how this might accomplish the desired goal?
> Being able to set the base address to start the search for a region
> of addresses to use when a process calls mmap(0, ...) has merit.
> Forcing every new process in the system to use the same settable value
> sounds like trouble.
I fully agree that it would be better to let each process decide for
itself. I just don't know how to do this.
All new processes are currently forced to use the same value. It
would be far better if this were somehow tunable.
Perhaps an environment variable could be used. I would not object
to a few limited choices, rather than a hex value.
I don't know how to do this or even if it is possible for
kernel code to read the environment variables.
Another suggestion, from another poster, was to modify the .so
loader, and I would think that it could easily read an
environment variable. Again, this is beyond my expertise.
Perhaps there are other suggestions for how to do this.
Currently the value used is TASK_UNMAPPED_BASE which has many
different values depending on which .h file you look at. Some of these
are already dynamic (mostly the 64 bit systems, where this is not going
to be a problem for many years to come anyway).
For example, a search:
./asm-arm/arch-integrator/memory.h:#define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
./asm-sh/processor.h:#define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
./asm-ia64/processor.h:#define TASK_UNMAPPED_BASE (current->thread.map_base)
./asm-mips64/processor.h:#define TASK_UNMAPPED_BASE ((current->thread.mflags &
MF_32BIT) ? \
./asm-s390/processor.h:#define TASK_UNMAPPED_BASE (TASK_SIZE / 2)
./asm-parisc/processor.h:#define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
./asm-cris/processor.h:#define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
./asm-s390x/processor.h:#define TASK_UNMAPPED_BASE ((current->thread.flags &
S390_FLAG_31BIT) ? \
./asm-alpha/processor.h:#define TASK_UNMAPPED_BASE \
((current->personality & ADDR_LIMIT_32BIT) ? 0x40000000 : TASK_SIZE / 2)
Some values for TASK_SIZE are:
./asm-i386/processor.h:#define TASK_SIZE (PAGE_OFFSET)
./asm-alpha/processor.h:#define TASK_SIZE (0x40000000000UL)
./asm-arm/arch-l7200/memory.h:#define TASK_SIZE (0xc0000000UL)
./asm-s390/processor.h:#define TASK_SIZE (0x80000000)
./asm-cris/processor.h:#define TASK_SIZE (0x50000000UL) /* 1.25 GB */
./asm-cris/processor.h:#define TASK_SIZE (0xB0000000UL) /* 2.75 GB */
./asm-s390x/processor.h:#define TASK_SIZE (0x40000000000UL)
TASK_UNMAPPED_BASE is then typically 0x40000000 on intel.
An alternative is to make this a parameter in the .config file for
building a custom kernel. True, that does not solve _my_ problem,
I would still need to build a kernel, but at least it would make
it easier for me to explain to users how to get this ability.
I am also leaning once againg to using a program to patch this at runtime,
I just need to figure out how to locate the value in memory in a
standard 2.4 kernel as distributed by redhat.
>
>
> --
> John Reiser, [EMAIL PROTECTED]
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: why un*x does not support select/poll events on directories?
Date: 8 Jun 2001 17:43:43 GMT
Alexander Viro <[EMAIL PROTECTED]> wrote:
> In article <9fqpek$2ge$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>>
>>if everything is a file why not unix designers add directory events to
>>select/poll system calls?
> Because select/poll is not a part of design, it's a hack added afterwards.
> Broken one, at that.
I'm curious on why they did not add directory events,
in linux directories events have been implemented in fcntl (see
Documentation/dnotify.txt)
I'm curious why not add it to select/polll... even if it's a hack, the hack
has been a standard
Ulisses
> --
> "You're one of those condescending Unix computer users!"
> "Here's a nickel, kid. Get yourself a better computer" - Dilbert.
--
Debian GNU/Linux: a dream come true
=============================================================================
"Computers are useless. They can only give answers." Pablo Picasso
------------------------------
From: John Reiser <[EMAIL PROTECTED]>
Subject: Re: how can I get a change to "official" linux? (found something new)
Date: Fri, 08 Jun 2001 12:10:56 -0700
> > Have you considered making the base address part of ulimit()?
> > This would protect other processes from interference, yet provide
> > an inheritable paramter for selected process trees.
>
> I don't understand this, could you explain a bit what you mean
> and how this might accomplish the desired goal?
Look at "man setrlimit" and /usr/include/bits/resource.h .
There are several parameters that can be set on a per-process basis.
Also, a child process inherits its initial values from its parent.
Things like the maximum sizes of data, stack, core files, etc.
(RLIMIT_DATA, RLIMIT_STACK, RLIMIT_CORE). Setting RLIMIT_CORE to 0
is a way to prevent memory dumps in response to SIGSEGV, for instance.
You could add RLIMIT_MMAPBASE to specify the base address
to be used as the starting point for the search for enough room
when calling mmap(0, ...) with MAP_FIXED not set. Setting
RLIMIT_MMAPBASE would affect subsequent mmap() in the current
process, and all calls from child processes, until reset.
If you made the shell 'ulimit' command aware of RLIMIT_MMAPBASE,
just like the shell knows about RLIMIT_CORE, then you could set
the base address for all children of a shell. You could also
write a helper program
mmapbase 0xa0000000 myprog arg1 arg2 arg3
which would perform the setrlimit, then execve() "myprog arg1 ...".
> [snipped]
--
John Reiser, [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: why un*x does not support select/poll events on directories?
Date: 8 Jun 2001 16:11:09 -0400
In article <9fr2sf$3in$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
>> Because select/poll is not a part of design, it's a hack added afterwards.
>> Broken one, at that.
>
>I'm curious on why they did not add directory events,
Think of network filesystems. There you have no way to generate such
events without sending a packet storm upon every file creation.
>in linux directories events have been implemented in fcntl (see
>Documentation/dnotify.txt)
I know. dnotify is even uglier hack. Unfortunately it made its way into
the kernel - mostly due to the efforts of filemanager writers (spit) and,
IIRC, samba folks.
>I'm curious why not add it to select/polll... even if it's a hack, the hack
>has been a standard
What are you going to use them for?
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: "Binesh Bannerjee" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.security,comp.os.linux.misc,comp.os.linux.development.apps
Subject: Re: Matt Blaze's CFS on Linux - readdir problem.
Date: 8 Jun 2001 21:34:32 GMT
In comp.os.linux.security Kevin Buhr <[EMAIL PROTECTED]> wrote:
Thanks, this was most helpful... I unfortunately have the whole CFS
source all torn apart now, and have ripped through the code,
ANSIfied everything, and gotten it to compile without any warnings
now... (Well, maybe not really unfortunately)... I've made the changes
you said, when I finally run it, I guess we'll see what happens...
Have you done much with cattach -l ? Do you know how that works?
I noticed some interesting _other_ problems with cattach -l...
But, maybe it's just a more radical version of the same problem...
Basically, with cattach -l after I add enough directory entries,
the _entire_ directory becomes invisible... (There still there, just
ls or find, whatever won't find them, but you can cd to the directories,
vi files etc.)
Second question regards cfs_adm.c
The file defines
typedef struct svc_req *SR;
and later defines
cfsstat *admproc_attach_2(ap, rp)
cfs_attachargs *ap;
SR *rp;
while in admproto.h theres a declaration for
extern cfsstat * admproc_attach_2_svc(cfs_attachargs *, struct svc_req *);
(I understand that the _2 in the cfs_adm.c, and cfs_nfs.c need to be
changed to _2_svc because of Linux rpcgen...) But, is the definition
still wrong, because SR *rp effectively becomes struct svc_req **rp?)
Still plugging away, anyhow tho...
Binesh
: It's a kernel/C-library bug that's difficult to fix completely. The C
: library does some fancy double-buffering in getdents(2) and so must
: occassionally lseek on directories behind the scenes. When reading
: from NFS filesystems whose files have large (>0x8000000) NFS cookies,
: it will occassionally issue directory lseeks to negative offsets
: without checking for an error return value. This is highly dependent
: on internal C library buffer sizes, and will result in silently
: disappearing files that vary from application to application. For
: NFSv2, you can fix this particular problem by having the C library
: llseek in this situation; for NFSv3---where the cookies are 64 bits,
: it'll still be broken
: Note that this isn't normally a data-destroying bug---your files are
: still there; it's just that some applications won't "see" some files.
: "rm -rf" might give you a mysterious "directory not empty"; or after a
: "mv * elsewhere", you might be surprised to discover the current
: directory is still full of files that were missed on the first pass.
: There's more on this in a "linux-kernel" thread with subject:
: negative NFS cookies: bad C library or bad kernel?
: dated December 2, 2000.
: The easiest fix is to modify CFS to use small NFS cookies. CFS
: actually uses small host-endian cookies that, on little-endian
: architectures, become large cookies in NFS space. This isn't a CFS
: *bug*: cookies are supposed to be arbitrary. However, it just happens
: to tickle this Linux bug, and we can "fix" it by having CFS convert
: cookie values to network byte order.
: I've enclosed a patch against Debian CFS 1.3.3-9; it will apply
: against vanilla CFS 1.3.3 with some fuzz. Note that this modification
: won't introduce any compatibility problems with existing or new CFS
: directories---it only changes the values of the temporary cookies
: passed between the CFS server and the kernel, not anything to do with
: the CFS storage format. As always, test on a trash CFS directory
: before trying it on your pr0n collection or anti-government tract
: archive.
: Kevin <[EMAIL PROTECTED]>
: * * *
: diff -ru cfs-1.3.3/cfs_nfs.c cfs-1.3.3-new/cfs_nfs.c
: --- cfs-1.3.3/cfs_nfs.c Wed Jun 6 00:37:40 2001
: +++ cfs-1.3.3-new/cfs_nfs.c Wed Jun 6 00:34:34 2001
: @@ -873,7 +873,7 @@
: ne=0;
: prev= &ret.readdirres_u.reply.entries;
: *prev=NULL;
: - bcopy(ap->cookie,&cookie,sizeof(cookie));
: + cookie = ntohl(*(unsigned long*)(ap->cookie));
: eof=TRUE;
:
: key=keyof(h);
: @@ -910,7 +910,7 @@
: else if (strcmp(s,"..")==0) /* parent */
: entrytab[ne].fileid=fhpid(h);
: else entrytab[ne].fileid=dent->d_fileno;
: - bcopy(&cookie,entrytab[ne].cookie,sizeof(long));
: + *(unsigned long*)entrytab[ne].cookie = htonl(cookie);
: *prev = &entrytab[ne];
: prev = &entrytab[ne].nextentry;
: entrytab[ne].nextentry=NULL;
: @@ -1127,7 +1127,7 @@
: ne=0;
: prev= &ret.readdirres_u.reply.entries;
: *prev=NULL;
: - bcopy(ap->cookie,&cookie,sizeof(long));
: + cookie = ntohl(*(unsigned long*)(ap->cookie));
: eof=1;
:
: ret.status=NFS_OK;
: @@ -1146,7 +1146,7 @@
: else entrytab[ne].fileid=dent->d_fileno;
: cookie=dent->d_reclen; /* may not work everywhere */
: *prev = &entrytab[ne];
: - bcopy(&cookie,entrytab[ne].cookie,sizeof(long));
: + *(unsigned long*)entrytab[ne].cookie = htonl(cookie);
: prev = &entrytab[ne].nextentry;
: entrytab[ne].nextentry=NULL;
: ne++;
------------------------------
From: "gdm" <[EMAIL PROTECTED]>
Subject: rh6.2 with shm of 1Gb?
Date: Fri, 8 Jun 2001 21:01:51 +0200
is it possible to have a Redhat6.2 with a big shm of 1Gb?
gdm
------------------------------
From: [EMAIL PROTECTED] (v.nagasrinivas)
Subject: while browsing severely encountering ZOMBIE and stucking up..
Date: Sat, 9 Jun 2001 03:01:42 +0000 (UTC)
Hi,
I am Using SuSE 6.3 and the kernel is of 2.2.13.
when i open two netscape windows, after browsing to certain links..
one of the process going to ZOMBIE, or one of the netscape window
( showing the command line as 'dns helper' through task manager).
and chmod status as ZOMBIE concern to the netscape thread....
At this stage , even i close the netscape windows the processes existing
there...I have to kill them forcefully (manually,).
What exactly happening
Can any give some knowledge to me........
thanks
srinivas.
--
v.naga srinivas
YVL SoftwareConsultancy,
B4,Q1,6th floor,
CyberTowers,Hi-Tec city,
Madhapur,Hyderabad-500033
Andhra Pradesh State
INDIA.
ph(office):091-040-3110200
visitme http://www.nagasrinivasv.com
--
Posted from ns.stph.net [196.12.32.2]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: [EMAIL PROTECTED]
Subject: Porting from NetBSD to Linux
Date: 9 Jun 2001 09:48:37 GMT
Hi guys,
Does anyone has any experience in porting BSD kernel sources to Linux kernel? I am
working on some networking stuff
and I need to port from NetBSD to Linux. Aftering reading through 4.4BSD Operating
System and Linux Device Drivers,
I come to the conclusion that the major differences between the two are BSD uses mbuff
as data structures for sockets
and Linux uses sk_buff. The other different thing I had noticed is that BSD has a
protocol switch table structure which
is absent in Linux, I have the impression that the protosw.h is not implemented in
Linux, am I correct? What are the
other major differences?
I need to recompile the kernel with my new code. How can I go about integrating the
new source into the Linux kernel?
What do I need to do for the Makefile?
Many thanks in advance!
Cheers,
Jonathan
------------------------------
Date: Sat, 09 Jun 2001 14:19:54 +0200
From: Marcel Baur <[EMAIL PROTECTED]>
Subject: Type iso_t
Does anyone know how and where type iso_t is defined?
I found references in sys/types.h but didn't get very far.
sizeof(iso_t) gives me a size of 4 bytes, but I can't believe
iso_t is simply an int.
Thanks for any help on this issue.
Cheers,
Marcel
------------------------------
Date: Sat, 09 Jun 2001 14:23:32 +0200
From: Marcel Baur <[EMAIL PROTECTED]>
Subject: Re: Type iso_t
I for myself wrote:
> Does anyone know how and where type iso_t is defined?
> I found references in sys/types.h but didn't get very far.
> sizeof(iso_t) gives me a size of 4 bytes, but I can't believe
> iso_t is simply an int.
s / iso_t / ino_t
Sorry for the mess.
------------------------------
From: "Maximus Idius2" <[EMAIL PROTECTED]>
Subject: winmodem source file can be modified ?
Date: Sat, 9 Jun 2001 22:05:39 +0900
Hi all,
I have a Rex-PCI56K, from Ratoc system, which has source file and make file
for
Turbolinux 5.0, 6.0; Redhat 6.1, 6.2, slackware, etc., yet it does not run
under
redhat 7.1 or 7.0.
The makefile and source ptmodule.c is below. I wonder if anyone can give
advice on what other files are needed and/or if they can be modified for
just generic winmodem ?
TIAM
maximus idius
---
--- MAKEFILE BEGINNING ----
#
# Makefile for the PCtel module
#
# Note! The CFLAGS definition is now inherited from the
# parent makefile.
#
HPATH = ../../include
FINDHPATH = $(HPATH)/asm $(HPATH)/linux $(HPATH)/scsi $(HPATH)/net
HOSTCC =gcc -I$(HPATH)
HOSTCFLAGS =-O -fomit-frame-pointer
CROSS_COMPILE =
COL_DEBUG_FLAGS =
AS =$(CROSS_COMPILE)as
LD =$(CROSS_COMPILE)ld
CC =$(CROSS_COMPILE)gcc -D__KERNEL__ -DMODULE -Wall $(HOSTCFLAGS) -I$(HPATH)
${COL_DEBUG_FLAGS}
CPP =$(CC) -E
AR =$(CROSS_COMPILE)ar
NM =$(CROSS_COMPILE)nm
STRIP =$(CROSS_COMPILE)strip
MAKE =make
EXTRA_LDFLAGS :=
# object files directory
O_TARGET := ../../lib/pctel.o
# object files
O_OBJS := \
ptmodule.o \
OX_OBJS := \
../../lib/control.a \
../../lib/hal.a \
../../lib/dsp.a \
../../lib/ptserial.a
all_targets: $(O_TARGET) $(L_TARGET)
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) -S $< -o $@
%.o: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c -o $@ $<
%.o: %.s
$(AS) $(ASFLAGS) $(EXTRA_CFLAGS) -o $@ $<
ifdef O_TARGET
ALL_O = $(O_OBJS) $(OX_OBJS)
$(O_TARGET): $(ALL_O) Makefile
rm -f $@
$(LD) -r $(EXTRA_LDFLAGS) -o $@ $(ALL_O)
endif
clean:
rm -f *.o
ifdef L_TARGET
rm -f $(L_TARGET)
endif
ifdef O_TARGET
rm -f $(O_TARGET)
endif
--- END MAKEFILE ----
---- Source: ptmodule.c ----
/*
* For the definition of __module_kernel_version[] so that
* the modem driver can be compatible with various Linux kernel
* versions.
*
* This file is to be linked with the rest of the libraries in
* the distribution package.
*/
#include <linux/version.h>
const char __module_kernel_version[] __attribute__((section(".modinfo"))) =
"kernel_version=" UTS_RELEASE;
#ifdef MODVERSIONS
const char __module_using_checksums[] __attribute__((section(".modinfo"))) =
"using_checksums=1";
#endif
--- END SOURCE ---
------------------------------
** 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
******************************
