Linux-Development-Sys Digest #773, Volume #8 Tue, 5 Jun 01 12:13:14 EDT
Contents:
Re: GNU_SOURCE ("Ivor Cox")
Re: Porting solaris software to Linux (Dragan Cvetkovic)
Re: creating files under /proc? (Kasper Dupont)
Re: mmap() and msync() extensions? (Kasper Dupont)
Re: Kernel (mal)function after harmless driver Segmenttion Error (Kasper Dupont)
Re: Help!! (Kasper Dupont)
Re: mmap() and msync() extensions? (Dragan Cvetkovic)
Re: Porting solaris software to Linux (Grant Edwards)
Re: thundering herd problem: the REAL scoop (Kasper Dupont)
Re: Lilo question (Kasper Dupont)
#include <linux/kernel.h> (root)
Re: SIGALRM - Please help!! (Kasper Dupont)
Re: how to access physical memory at specified address? (Kasper Dupont)
----------------------------------------------------------------------------
From: "Ivor Cox" <[EMAIL PROTECTED]>
Subject: Re: GNU_SOURCE
Date: Tue, 5 Jun 2001 14:23:48 +0100
Hi,
Where do I find out/read about the use/meaning etc for these options?
I know I need _GNU_SOURCE for recursive mutexes but there must be much more!
Cheers
Ivor
"Nix" <$}xinix{$@esperi.demon.co.uk> wrote in message
news:[EMAIL PROTECTED]...
> On 30 May 2001, Martin von Loewis stipulated:
> > I was confused. I remembered it would define "many" functions, but
> > mistook this that it would define everything it has.
>
> It's probably because libc5 *did* define lots of GNU-specific stuff
> (roughly what is now defined by -D_GNU_SOURCE); -D_GNU_SOURCE was
> introduced to let people keep using it, while aiding portability by not
> defining them for programs that don't expect/need it.
>
> --
> `Technology is meaningless. What matters is how people _think_
> of it.' --- Linus Torvalds
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer,comp.unix.solaris
Subject: Re: Porting solaris software to Linux
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 05 Jun 2001 09:35:05 -0400
[EMAIL PROTECTED] (phil) writes:
>
> One huge section that is completely different on Linux and Solaris,
> is threads. Solaris has it's own thread Library, while Linux uses
> it's POSIX thread library.
Well, Solaris does have its own thread library, but also has POSIX one, so
all POSIX thread functions are supported.
>
> Semaphores are another area where this happens again, Linux
> conforming somewhat to the POSIX standard and Solaris with it's own
> semaphore functions.
They both support SYSV IPC semaphores (semctl, semget, semop) which most of
the people still use. I didn't know that Linux supports POSIX ones
(sem_close, sem_init, sem_post etc.), but, since I have man pages for them
it obviously does :-)
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: creating files under /proc?
Date: Tue, 05 Jun 2001 13:57:59 +0000
Timur Tabi wrote:
>
> I have a driver which creates a directory and a couple files under
> /proc, namely /proc/zfc/. Is it possible to create new files in
> /proc/zfc/ using the ln, cat, or cp commands? I can't seem to find any
> examples of doing that, so I'm not sure whether it can be done (or where
> to look to find out).
>
The proc filesystem has no support for creating
new entries from userspace programs. I think it
will be posible to add that support, but it will
require some work to do it.
If you really think you need it then try
explaining in detail why you need it. Then we
will be able to say wether it is a good idea or
not.
To be able to create files under /proc from
userspace, you will have to add fields to the
file_operations structures used by the proc fs.
Since the new fields might cause bad
interference with the rest of the proc fs, I
suggest you don't actually change the structures
being used, but instead make a copy in which you
add the new fields.
Doing all this might not be posible without
exporting more symbols from the kernel. If it
would require too many changes to the existing
kernel to do what you want, it might be a much
better idea to simply write a new virtual fs.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: mmap() and msync() extensions?
Date: Tue, 05 Jun 2001 14:08:19 +0000
bill davidsen wrote:
>
> In article <[EMAIL PROTECTED]>,
> At150bogomips <[EMAIL PROTECTED]> wrote:
> |
> | Bill Davidsen <[EMAIL PROTECTED]> wrote:
> | > It works that way now... unless the mlock() call is used, the kernel
> | >brings in only what you use. That's what "demand paging" means.
> | >
> |
> | Sorry. Merely showing my ignorance. However, there does not seem to be a
> | syscall to communicate usage hints (as the previously pointed to madvise on
> | Solaris).
>
> Hopefully a bored developer is reading this thread ;-) But I'm not
> sure how much all this advisory really helps in real life. It would be
> most useful in systems with inadequate hardware, trying to get the last
> drop out of not enough memory.
>
> Since there is an existing model, if it gets done at all hopefully it
> will get done compatibly.
>
The Linux kernel does have a madvise() system call.
I think madvise() appeared in the 2.4.x, but I don't
know the details. Of course compatibility with
Solaris would be preferred, unless the Solaris call
is hopelessly bad designed.
Since ignoring all madvise() calls doesn't break
anything but performance compatibility should be
very easy to achieve.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Kernel (mal)function after harmless driver Segmenttion Error
Date: Tue, 05 Jun 2001 14:27:40 +0000
Norm Dresner wrote:
>
[...]
>
> In the instance in question, I didn't corrupt anything; that's guaranteed:
> all I did was to add a single additional memory reference to read from an
> address that I knew would produce a segmentation error; since the data was
> read into a temporary variable, there's absolutely no chance of corrupting
> the kernel in any way.
>
[...]
You cannot be sure about that.
Your function was called from some other function
somewhere in the kernel. When you don't even know
which function called your function how on earth
would you be able to say anything about what that
function was doing.
The function could have been locking some kernel
data structures and be in the middle of chaning
them when it called your functions. Since you you
cause an abrubt termination of the process, the
system will either have to keep the lock causing
deadlock situations or releasing the lock
prematurely causing inconsistency in the kernels
data structures.
In both cases the system will become unstable,
and that the system doesn't crash right away is
just pure luck.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Help!!
Date: Tue, 05 Jun 2001 14:36:44 +0000
M.C. enicon wrote:
>
> psy <[EMAIL PROTECTED]> wrote in message
> MRQP6.4450$[EMAIL PROTECTED]
> > As a Linux newbee, I installed RedHat 7.1 successfully even though I am
> > having some darn problems (which is normal when you don't master a new
> > OS!!).
>
> > 3- When I put a cd on my cd-rom hardware, it works fine but I cannot
> re-open
> > the door anymore!! I pressed the exit button many times, without any
> > success... What did I do wrong?
>
> Don't forget to umount it! Usually it is achiavable from the terminal with
> #umount /mnt/cdrom
>
> Maybe you should use /cdrom and not /mnt/cdrom, to check it see the table
> printed by mount
> If the unit is not busy then you can eject, both with button or via
>
> #eject /dev/cdrom
>
> Ciao, Massimiliano
If you are using KDE or Gnome you can rightclick
on the CDROM icon and choose Eject after quiting
all programs using the disk.
--
Kasper Dupont
------------------------------
Subject: Re: mmap() and msync() extensions?
From: Dragan Cvetkovic <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: 05 Jun 2001 10:48:48 -0400
Kasper Dupont <[EMAIL PROTECTED]> writes:
>
> I think madvise() appeared in the 2.4.x, but I don't
> know the details. Of course compatibility with
> Solaris would be preferred, unless the Solaris call
> is hopelessly bad designed.
Well, Solaris madvise supports the following options:
#define MADV_NORMAL 0x0 /* No further special treatment */
#define MADV_RANDOM 0x1 /* Expect random page references */
#define MADV_SEQUENTIAL 0x2 /* Expect sequential page references */
#define MADV_WILLNEED 0x3 /* Will need these pages */
#define MADV_DONTNEED 0x4 /* Don't need these pages */
#define MADV_FREE 0x5 /* Contents can be freed */
but I have no opinion if it is bad designed or not.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps,comp.unix.programmer,comp.unix.solaris
Subject: Re: Porting solaris software to Linux
Date: Tue, 05 Jun 2001 14:50:58 GMT
In article <9fhrtj$cho$[EMAIL PROTECTED]>, jamal wrote:
>I am new in linux or unix programming in general.
>My company has an application written for Windows and Solaris.
>We plan to port it to Linux.
First, I'd get it to build under Solaris with Gnu tools (gcc,
gnu make).
Once you've got it ported to gcc, then try moving it to Linux.
That will involve various (relatively minor, in my experience)
libary incompatibilities. One thing that I always ran into
were small differences in the handling of signals: whether
system calls are restarted, and wheter signal handlers have to
be re-installed with every signal. It's possible to write
signal code that works right on both systems (without #ifdefs),
but the typical way of doing things on one system doesn't work
quite right on the other.
--
Grant Edwards grante Yow! Are you mentally here
at at Pizza Hut??
visi.com
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.programmer,comp.unix.bsd.freebsd.misc
Subject: Re: thundering herd problem: the REAL scoop
Date: Tue, 05 Jun 2001 15:13:29 +0000
[EMAIL PROTECTED] wrote:
>
[...]
>
> The two specific problems in more detail are:
>
> 1. Multiple processes have non-blocking sockets for which listen() has
> been called, and because they have other descriptors, they must use the
> select() or poll() system calls to wait for an active descriptor. When
> the listening socket receives a new connection, the descriptor for every
> process is now technically an active descriptor, and select() or poll()
> wakes up in each and every process. Every process now races to do the
> accept() call, but only one process will succeed and get a new socket
> descriptor and service the connection. All the rest will get an error
> with an EAGAIN or EWOULDBLOCK error number, and go back to sleep in the
> select() or poll() call.
>
Surely the two problems you mention is both thundering
herd problems. The difference is that #1 is a thundring
heard problem in user space and #2 is a thundering herd
problem in kernel space.
Problem #2 can simply be solved by changing the kernel
code where there actually is a problem.
Problem #1 cannot simple be solved by chaning the kernel
because the problem is somewhere else namely in the
userspace program calling select() or poll().
[...]
>
> There is one potential problem with doing "wake one" on select() or
> poll(). If one connection arrives and one process wakes up, if that
> process decides to do something else instead, or otherwise fails to
> execute the accept() call, there remains a pending connection on the
> queue. When another connection arrives, if only one more process now
> wakes up, it would likely accept() just the first connection, leaving
> the second connection still pending. Now we have an "off by one" kind
> of problem in the queueing. These kinds of things could be solved, but
> it would take some extra kernel logic to do, possibly a lot to shut all
> the exposures.
>
[...]
In this case there surely is a problem in the userspace
program. If this is a problem common to many userspace
programs it might be a good idea to find a way to solve
the problem by changing the kernel. But of course it is
not possible to have the kernel solve all thundering herd
problems in all userspace programs. And of course we may
not break semantics when trying to solve some of the
problems.
Trying to use wake on semantics inside the kernel will
solve the thundering herd problem. But it will introduce
incorrect semantics in the case where the process being
waked up does not make use of the file descriptor
causing the wakeup.
I don't think we should discard the idea because it in
some cases introduce incorrect semantics. Instead we
can create a workaround achieving the correct semantics
in these rare cases.
We can wakeup one process and remember the fact, that
we have a waitqueue that must be waked up unless the
current process does a read/write/accept or whatever
call very soon. When the process goes to sleep or is
preempted, and the file descriptor is still ready we
wakeup one more process. We continue this way until
the file descriptor is no more ready, or the waitqueue
is empty.
This will require some additional information stored
in the file structures, and will require minor changes
to the scheduler and/or interrupt handling. But it
surely is a feasible way to solve the problem. Can
anybody see any way this will break any semantics. (It
might change semantics, but as long as it remains Posix
compliant I don't consider it to be broken.)
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Lilo question
Date: Tue, 05 Jun 2001 15:24:44 +0000
Hugin wrote:
>
> Hello,
>
> My bios is set to boot in this sequence : "A,C,SCSI"
> If I install Lilo on drive C, is there a way I can
> make Lilo continue the boot-sequence? Eg. When
> I start Lilo, it displays the different Linux-startups.
> Can I then make Lilo quit(?), and make it continue
> on the booting sequence set by BIOS (eg. SCSI)?
>
I have an idea that might work.
If the harddisk has standard MBR code installed, but
no active partition, the MBR code will scan the
partition table and finally execute an INT 0x18
instruction. (0x18 is the ancient ROM BASIC call.)
I think a newer bios will have INT 0x18 mapped to
the code continuing the boot sequence. If I'm
right about this making LILO call this interrupt
should do it.
If LILO doesn't already have that feature, it can be
added by changing the LILO code.
If you don't want to change the LILO code, you can
find a partition you don't usually boot from, and on
that partition install code to call INT 0x18.
The code to call int 0x18 is the two bytes 0xCD, 0x18.
Also remember to add the boot signature to the last
two bytes of the block. It is the two bytes 0x44 and
0xAA, I'm not sure about the order of the two bytes.
Be carefull not to overwrite important data in the
disk block in question, some filesystems does keep
important data in this block.
--
Kasper Dupont
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: #include <linux/kernel.h>
Date: Tue, 05 Jun 2001 10:36:24 -0500
I've started working on a device driver. However, all of the constants
defined in kernel.h (for example KERN_DEBUG) are unresolved by the
compiler (gcc). My include statement is:
#include <linux/kernel/h>
The compiler does not complain about its location at all.
Thanks.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: SIGALRM - Please help!!
Date: Tue, 05 Jun 2001 15:38:47 +0000
^CooL^ wrote:
>
> Hi everyone.
>
> I am working on a POSIX-like user-level thread library that does not
> rely on the
> underlying kernel system calls to switch context between threads, etc,
> making it a faster solution than kernel-level threads. I am using GNU
> C on Red Hat Linux 7.
>
> Now first of all, I know there is POSIX that already does all that,
> but I need this for a university project - so I can't just use POSIX!
> :-)
>
> Anyway, I need to use SIGALRM to implement pre-emptive
> multi-tasking....
> Every a pre-stipulated pre-emption interval, a thread is interrupted
> and is forced to yield.... I am using signam (SIGALRM, sig_handler) so
> that everytime the interrupt is generated, the function sig_handler
> calls the thread's yield() function automatically.
>
> Now the problem is that the yield() function performs a longjmp which
> does not return, and therefore the interrupt handling does not return
> either! For this reason, it seems that once the interrupt occurs a
> first time, it does not occur anymore times after that - sort of
> locks!
>
> Here's more or less what I'm talking about:
>
> void sig_handler (int arg) {
> yield();
> }
>
> void yield () {
> // Scheduling operations such as setjmp go here...
>
> // Re-schedule another interrupt
> signal (SIGALRM, sig_handler);
> value.it_value.tv_usec = preempt_interval;
> setitimer(ITIMER_REAL,&value,&value2);
>
> // Switch context
> longjmp (...); // This call does not return
> }
>
> int main () {
> // Schedule first interrupt
> signal (SIGALRM, sig_handler);
> value.it_value.tv_usec=1000000;
> setitimer(ITIMER_REAL,&value,&ovalue);
>
> // start running first thread.
> setjmp (..);
> (longjmp (...);
> }
>
> Got the idea now? It does work well the first time... In fact, the
> first running thread IS interrupted and the first context switch
> occurs, BUT after that no other interrupt is generated, and the second
> running thread will run forever unless it voluntarily yields!
>
> Anyone has any idea how I could solve this problem?
>
> Regards and thanks,
> Clyde.
First of all sigsetjmp() and siglongjmp() will
probably be better for your purpose as you can
tell them to save and restore signal masks.
Second I'm not sure that this is actually enough,
as these functions doesn't necesarilly save
CPU registers. Another problem is that you need
to have different stacks for the different
processes, sigsetjmp() and siglongjmp() cannot
do that for you.
Does your code need to be portable? If your code
only needs to run on Linux i386 I can give you
a lot more advices.
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: how to access physical memory at specified address?
Date: Tue, 05 Jun 2001 15:45:55 +0000
Christoph Pacher wrote:
>
> > > I need to read/write memory blocks at a specified address space to test
> > > DRAM chips. Is there a possibility to prevent the kernel (and
> > > applications) from using/allocating predefined memory blocks?
> >
> > Yes. Adding to the kernel prompt mem=128M on a 256MB system leaves the
> > top 128MB of RAM untouched and you can use them as you wish.
> >
>
> Thanks, I think this will help me on my next steps!
> But in the case that I will need to reserve memory space at an arbitrary
> position (e.g. between 32MB and 64MB on a 256MB system) is there another
> method?
>
> I can image that there is some linker option I can use while linking a new
> kernel..., but if somebody know more about it, please let me know!
>
> --
> Christoph Pacher
There was a posting a few weeks ago stating a syntax
to specify an arbitrary memory layout. I don't
remeber the exact details, but I think it was something
like mem=64MB@128MB to use 64MB starting at address
128MB.
Just notice, that this will not prevent the system from
using the first 4MB of the physical address space.
--
Kasper Dupont
------------------------------
** 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
******************************
