Linux-Development-Sys Digest #786, Volume #8     Thu, 14 Jun 01 08:13:12 EDT

Contents:
  where is this kernel code? (Aravindh)
  Re: Shared memory RDONLY question (Ulrich Weigand)
  Re: thundering herd problem: the REAL scoop ([EMAIL PROTECTED])
  Re: where is this kernel code? (Adam Fineman)
  Re: distros we'd like to see (\\_0_/)
  Re: pause the bootup ("Karl Heyes")
  Strange behaviour of the Round Robin policy (Didier Siron)
  Re: where is this kernel code? ("Peet Grobler")
  Supervising non-child processes w/wo procfs ("Guido Ostkamp")

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Aravindh)
Subject: where is this kernel code?
Date: 13 Jun 2001 15:21:12 -0700

hi,

i was looking for the code in the kernel where it displays "Press 'I'
to enter interactive..." and I am just not able to find it. Also where
is the code once the system goes into interactive mode. For ex - where
is the code for "Start service kudzu (Y)es/(N)o/(C)ontinue?"

thanks
aravindh

------------------------------

From: [EMAIL PROTECTED] (Ulrich Weigand)
Crossposted-To: comp.unix.aix,comp.unix.programmer
Subject: Re: Shared memory RDONLY question
Date: 14 Jun 2001 00:53:09 +0200

Rob Yampolsky <[EMAIL PROTECTED]> writes:

>The man page on Linux 2.2 doesn't explicitly say you need to use mmap 
>(and in fact has an example of using mprotect on a malloc'd buffer). 
>But it does carry a footnote that states:

>POSIX.1b says that mprotect can be used only on regions of memory 
>obtained from mmap(2).

>So, what's the bottom line?  Can't do it on AIX, can on Linux?

Yes, I was talking about Linux.  In fact I wasn't sure what POSIX 
said about this, but according to your quotes it's quite clear ...

>If I were to convert my shmat() stuff to mmap, would I have to map the 
>memory to the filesystm?  Don't see any way for multiple processes to 
>share the same segment other than via the 'fildes' parameter.

The usual way would be to create a temp file, open it, unlink it
(so that is doesn't appear in any directory anymore and will get
cleaned up automatically once noone uses it anymore), and map it.

For multiple processes, either you don't unlink it and access it
by name, or else you pass the fd around (either inheriting across
fork() or passing it via sendmsg()).

Yet another option altogether would be to use the new POSIX shared
memory API.  You use shm_open() to open a named shared memory segment,
which returns a fd that you can then mmap().  As that mapping *is*
established by mmap(), mprotect() should work in this case even
according to POSIX ...  (However, the question is whether all 
platforms you want to use have implemented POSIX shared memory already.)


-- 
  Dr. Ulrich Weigand
  [EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.unix.programmer,comp.unix.bsd.freebsd.misc
Subject: Re: thundering herd problem: the REAL scoop
Date: 13 Jun 2001 22:54:32 GMT

In comp.unix.programmer Rasputin <[EMAIL PROTECTED]> wrote:
| In article <[EMAIL PROTECTED]>, Andrew Gierth wrote:
|>>>>>> "phil" == phil-news-nospam  <[EMAIL PROTECTED]> writes:
|> 
|> phil> FreeBSD's kqueue/kevent syscalls could easily be made to solve
|> phil> this problem.
|> 
|> I think this is harder than it sounds. Since kqueues can't be shared
|> between processes (at least in -STABLE), you have essentially the same
|> problem in that you have N processes each with a kevent filter for the
|> accept, and you have to direct the incoming connection to exactly one
|> of them; the kernel has no way to choose which is the right one.
|
| IANA kernel hacker, but reading the kqueue docs, it appears that the 
| design is proposed as an alternative to multiple children/threads.
|
| It's supposed to allow a single process to manage many file descriptors
| without the conventional overhead of mechanisms like select/poll.

That is the design intent.  But by the fact that it is doing things
in a more "atomic" way ... that is, more things are done in one call
rather than many ... it can also help solve the process-space version
of the thundering herd problem by combining the action of select with
the action of accept.  Because waking up the process is combined with
committing the process to an incoming connection (the usual way of
calling accept() makes that commitment at a delayed point in time),
the kernel would know that it does not need to wake up some other
process.

So kevent() can be used for both the model of having one process do
all the work (some services are better suited to this model) as well
as multiple processes doing discrete work (other services are better
suited to this model).  It's really a very universal facility.

-- 
=================================================================
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/     |
=================================================================

------------------------------

From: Adam Fineman <[EMAIL PROTECTED]>
Subject: Re: where is this kernel code?
Date: Wed, 13 Jun 2001 20:08:04 +0000

Aravindh wrote:
> 
> hi,
> 
> i was looking for the code in the kernel where it displays "Press 'I'
> to enter interactive..." and I am just not able to find it. Also where
> is the code once the system goes into interactive mode. For ex - where
> is the code for "Start service kudzu (Y)es/(N)o/(C)ontinue?"
> 
> thanks
> aravindh

That functionality is provided by your particular linux distribution and
not by the kernel.

If you are running under RedHat, check out /etc/rc.d/rc.sysinit

HTH
--
Adam

------------------------------

From: \\_0_/ <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: distros we'd like to see
Date: Wed, 13 Jun 2001 18:14:55 -0600

you have *way* too much time on your hands :)


cLIeNUX user wrote:

> AOLinux
> American Federation of Linux and Congress of International OSen
> American Telephone and Linux Corporation
> Apricot Linux Company
> Bavarian Linux Works
> Bechtelinux Group
> Borlinux International
> Briggs, Linux and Stratton
> Bristol-Linux Squibb
> Cargillinux
> Caterpillinux Infotractor Company
> Chevrolinux
> Coca-Linux Bottling Company
> Daimlinux Chrysler
> Disneylinux
> Exxon Linux Mobil
> Federal Linux
> Ford Linux Company
> Friedman, Billings, Linux Group
> Frito-Linux
> Generalinux Electric
> Generalinux Mills
> Harlinux Davidson
> I.E. Linux de Nemours &Co.
> International Linux Machines
> Interstate Linux Commission
> JP Linux Chase
> Jack in the Linux Box
> Lintelux
> Linux Aerospeciale
> Linux Broadcasting Company
> Linux du Soleil
> Linux Scouts of America
> Linux Zepplin
> Linux-Suisse
> LinuxDesk Inc.
> Llynux of London
> M&M Linux
> McGraw Linux
> Mercedes Linux
> Metro Goldwyn Linux
> Minnesota Mining and Linux Company
> Motorolinux
> Motown Linux
> Neiman Linux
> Northrop Linux Grumman
> Oldsmolinux
> Paramount Linux
> Price-Linuxhouse
> Proctor, Linux and Gamble
> Prudential Linux Company
> RJ Linux NaOSco
> Sears, Linux and Company
> Southwest Linux
> Standard Linux of Ohio
> The New York Linux Exchange
> The United States Linux Corps
> This Old Linux
> U.S. Dept. of Linux
> United Linux Service
> Weyerlinux
> XerolinuX
>
> Rick Hohensee


------------------------------

From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: pause the bootup
Date: Thu, 14 Jun 2001 02:06:38 +0100

In article <[EMAIL PROTECTED]>, "Aravindh"
<[EMAIL PROTECTED]> wrote:

> hi,
> 
> i want to pause the bootup process by inserting "gets or scanf" inside the
> kernel code. how do i go about doing this. for example, i know that printk()
> is used to display messages. Is there some command I can add to the printk
> function that will wait for the user to press a key before continuing with
> the boot?

If you want to see the boot messages, just run dmesg or you can scroll the
console back with ctrl-pageup. The scroll back facility only works upto when 
you switch virtual consoles, so make sure init default isn't 5 in that case.

karl.

------------------------------

From: [EMAIL PROTECTED] (Didier Siron)
Crossposted-To: linux.dev.kernel
Subject: Strange behaviour of the Round Robin policy
Date: 14 Jun 2001 01:06:18 -0700

I'm using RedHat Linux V2.2.13 and I made the following test:

I launched 10 times the same program with priority 10 of Round Robin policy
(from a shell having priority 20 of FIFO policy). Each program does an infinite
busy loop (while (1)).
One minute later, I launched the "ps" command and I was expected that the TIME
values of all these processes are in an interval which is T large, where T is
given by sched_rr_get_interval() i.e. T=150ms in this release.

But the ps result was:
  PID TTY          TIME CMD
  652 tty1     00:00:00 login
 1549 tty1     00:00:00 bash
 1566 tty1     00:00:00 bash
 1596 tty1     00:01:12 my_program
 1597 tty1     00:00:02 my_program
 1598 tty1     00:00:01 my_program
 1599 tty1     00:00:01 my_program
 1600 tty1     00:00:05 my_program
 1601 tty1     00:00:01 my_program
 1602 tty1     00:00:00 my_program
 1603 tty1     00:00:16 my_program
 1604 tty1     00:00:01 my_program
 1605 tty1     00:00:00 my_program
 1610 tty1     00:00:00 ps

Does someone have any explanation of this behavior?
Thanks in advance.
Didier.

------------------------------

From: "Peet Grobler" <peetgr at absa.co.za>
Subject: Re: where is this kernel code?
Date: Thu, 14 Jun 2001 10:51:35 +0200

That's in your startup script. Which distro are you using? Mandrake stuffs
this in /etc/rc.d/rc iirc.

Aravindh wrote in message ...
>hi,
>
>i was looking for the code in the kernel where it displays "Press 'I'
>to enter interactive..." and I am just not able to find it. Also where
>is the code once the system goes into interactive mode. For ex - where
>is the code for "Start service kudzu (Y)es/(N)o/(C)ontinue?"
>
>thanks
>aravindh



------------------------------

From: "Guido Ostkamp" <[EMAIL PROTECTED]>
Subject: Supervising non-child processes w/wo procfs
Date: Thu, 14 Jun 2001 11:43:20 +0200

Hello newsgroup,

within a process I want to supervise a large number of other processes,
which have not been started by the supervising process; the supervising
process just knows the process IDs. Furthermore, supervising should 
be realized in a way, which doesn't waste CPU power, i.e. should be 
blocking, not actively polling.

In SystemV based systems this can be solved easily, you just have to 
open /proc/<pid> for each process and select/poll on the file 
descriptors. Whenever a process dies, the supervising process is 
informed by kernel and returns from the select/poll.

Unfortunately this doesn't seem to work with Linux.

Is there any implementation of the poll() system call for procfs?

Does somebody know other methods to solve the above problem?

Thanks in advance,

Regards,

Guido

------------------------------


** 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
******************************

Reply via email to