Linux-Development-Sys Digest #233

[Digestifier]

Linux-Development-Sys Digest #233, Volume #8 Tue, 24 Oct 00 15:13:13 EDT

Contents:
  advice needed on process hierarchies ("Richard Lim")
  Re: advice needed on process hierarchies (Alexander Viro)
  Re: using /linuxrc (Peter Pointner)
  Re: Accessing PCI I/O space (Peter Pointner)
  tcp connection queue size ([EMAIL PROTECTED])
  Re: Device or resource busy ("[EMAIL PROTECTED]")
  Re: using /linuxrc (Josef Moellers)
  Re: Which Gcc version to compile Linux Kernel ? ("O.Petzold")
  Q: Hauppauge TV without sound ("T. J. Domsalla")
  porting from SCO to linux problems? ("Martin Collins")
  Re: porting from SCO to linux problems? (ChromeDome)
  Re: Building a Driver ("Tony Aguilar")
  Re: Microsoft Linux API? ("J.H.Delaney")
  Re: tcp connection queue size (Kaz Kylheku)
  Re: Building a Driver ("Spam Me Not")
  Re: sockets per process ("Spam Me Not")



From: "Richard Lim" [EMAIL PROTECTED]
Subject: advice needed on process hierarchies
Date: Tue, 24 Oct 2000 12:45:15 +0800

Advice needed on the following:

Eg.
Question:
Write a pseudo C code to create the following process hierarchies using
fork:
   P1
/   |   \
P2   P3   P4

Solution:
pid = fork()
if (pid  0)
pid = fork()
if (pid  0)
pid = fork()

Question:
Write a pseudo C code to create the following process hierarchies using
fork:
   P1
/   |   \
P2   P3   P4
|  \
P5   P6
please advice on the solution.
I am not able to derive a solution for this one.
Is there a simple algorithms to follow to generate the C code to create the
process hierarchy of any kind.

regards,
richard lim





--

From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: advice needed on process hierarchies
Date: 24 Oct 2000 01:34:28 -0400

In article 8t342a$9v7$[EMAIL PROTECTED],
Richard Lim [EMAIL PROTECTED] wrote:
Advice needed on the following:

[snip the homework assignment]

please advice on the solution.
I am not able to derive a solution for this one.
Is there a simple algorithms to follow to generate the C code to create the
process hierarchy of any kind.

comp.unix.do.my.homework is - that way. Alternatively, you could try
to read the manpage of fork() and think for a couple of minutes. As soon
as you understand what fork() does this exercise will become completely
obvious. Any textbook/FAQ/whatever on UNIX should be sufficient to
get such understanding.

-- 
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

--

From: Peter Pointner [EMAIL PROTECTED]
Subject: Re: using /linuxrc
Date: 24 Oct 2000 07:15:27 +0200

Josef Moellers [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
 
 I'm about to make use of the /linuxrc feature.  I'm interested in any
 experiences people who have tried this for various purposes may have.
 I don't need any help (yet) on making this happen; I'm just wanting
 to be wary of any quirks I may encounter.

 AFAIK, despite the fact that the first line looks like a shebang calling
 /bin/bash, linuxrc is NOT a shell script and you won't be able to use
 (full) shell functionality there. You can put a few insmods in there,
 but that's about it.

Fortunately, it _is_ a shell script. From the kernel sources (2.2.13):

static int do_linuxrc(void * shell)
{
static char *argv[] = { "linuxrc", NULL, };

close(0);close(1);close(2);
setsid();
(void) open("/dev/console",O_RDWR,0);
(void) dup(0);
(void) dup(0);
return execve(shell, argv, envp_init);
}

I use linuxrc on an embedded system to start inetd and some other
processes. Works fine.

Peter


--

From: Peter Pointner [EMAIL PROTECTED]
Subject: Re: Accessing PCI I/O space
Date: 24 Oct 2000 07:18:18 +0200

Peter Huang [EMAIL PROTECTED] wrote:
 Hi

 with pci memory space. I can call pci_find_device and then ioremap to access
 a pci memory space.
 How do I access PCI I/O space?

By using I/O instructions (outb and friends). Since there are no virtual
I/O-addresses, you need no special step there.

If you need examples, the kernel sources are full of them.

 Peter
Peter


--

From: [EMAIL PROTECTED]
Subject: tcp connection queue size
Date: Tue, 24 Oct 2000 06:28:57 GMT

Hello,

I have a question about tcp socket connections in qeneral.

I was just wondering what is the default queue size relating to
incoming tcp connection requests that linux can handle right out of the
box.  Is there any way to change it and increase this queue size and
how?

thanks..

-john



Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: "[EMAIL PROTECTED]" [EMAIL PROTECTED]
Subjec

Linux-Development-Sys Digest #233

[Digestifier]

Linux-Development-Sys Digest #233, Volume #6  Thu, 7 Jan 99 19:14:04 EST

Contents:
  Re: Registry for Linux - Bad idea (Alexander Viro)
  Re: disheartened gnome developer (Perry Pip)
  Re: lp0 on fire in 2.1.131 (Bill Davidsen)
  Much easier way to crash X (Jeffrey Tsao)
  Re: Programming CDROM (Daniel N. Sands)
  Kernel 2.2.0-pre5 (compilation error) (Christoph Egger)
  Re: How to run Windows Applications on Linux (Bill Anderson)
  lock_kernel in 2.2.0pre4 w/o typo (David Grothe)
  lock_kernel in 2.2.0pre4 (David Grothe)
  Re: Why I'm dumping Linux, going back to Windblows (Roger Rabbit)
  Re: things I'd pay to have developed for Linux... (Andreas Dilger)
  Re: 2.2.0.pre4 fs/ntfs/inode.c compilation failure (N1ho)
  Re: Why I'm dumping Linux, going back to Windblows (Johan Kullstam)
  Re: disheartened gnome developer (jedi)
  Re: GUI, The Next Generation (Derek B. Noonburg)



From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry for Linux - Bad idea
Date: Sat, 02 Jan 1999 07:24:33 GMT

In article [EMAIL PROTECTED],
John R. Campbell [EMAIL PROTECTED] wrote:

   There is a *known* workaround to a registry-  and it is a proven
   technology.  While we whine and moan about the difficulty of
   dealing with it's file's, the MacOS implements all registry-like
   functions within the resource forks of files.

   I'm of the opinion that _this_ data/resource forking of file
   structures will be the "next big thing" for Linux to embrace;
   If we embed registry information into either the executables
   or data files, we can more easily maintain synchronicity.

Wake me up when you'll patch vi so that it could deal with that,
erm, stuff. Ditto for tar, sed, grep, awk, ftpd, yodda, yodda.

   Now all we need is a "trick" to allow us to use the data fork
   normally (transparent to the existing API) and still allow a
   means to re-focus a read on a resource fork.  It'd also be
   real nice to allow multiple "resource" forks, too...

Then wait till we'll have layered filesystems and implement
broken-as-Mac-fs to mount it atop of the file. Don't force this BS
on the rest of system. Or, better yet, read original PARC works miscopied
by Apple and figure out WTF resource fork is and what kind of environment
does it assume (MacOS lacks it). Hint: closures. When you'll rewrite the
system in functional language resource forks will be of great use. Please,
wake me up when it will happen.

-- 
Luser, n.:
Human-like creature that doesn't dare to use elevator, because of
its belief that only horrible geeks can master arcane and obscure art of
using control panel.

--

From: [EMAIL PROTECTED] (Perry Pip)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Reply-To: [EMAIL PROTECTED]
Date: Thu, 07 Jan 1999 19:32:14 GMT

On 7 Jan 1999 05:41:24 GMT, Navindra Umanee [EMAIL PROTECTED] wrote:
Agreed.  I'd add that people should also understand the implications
of GPL'ing their work.

And so it is with any software license. But what GPL strives to create
(perhaps not perfectly) is a "share and share alike" environment. In other
words, all developers are on the same level, all developers are treated as
equals and are working together. At least that's what the license strives
for.

[some dialog snipped - context here is QPL]
Sure you can fork the development.

 on a CVS repository and have yourself and others commit patches to on it.

Okay, here I admit I'm not sure what "in a form that is separate from
the Software" means.  Considering patches though, you can put the
patches themselves in CVS alongside the original tree (you can
generate diffs from the original easily enough from a local PRCS/CVS
tree).


And you can set up Gnu Autoconf to automagically apply the patches when
the ./configure script is run.

But suppose you fork the code and create your own version called NavQt,
distributed as patch+original. If your version becomes popular, Troll Tech
can instantly include your patches in their version, making it part of
thier *commercial* product, charging people money for the commercial
version. You are not on the same level with them. You do not have equal
rights, even to your own work, under the qpl. If you can accept that,
that's fine for you.

Redhat is spending $$$ on gnome development. But nowhere in the copyright
or license does it say that they exclusivly own or control it. They are
part owners of the copyright, and if you contribute a worthwhile patch,
you become a part owner too. Redhat plans to make money selling service
and support for gnome, which you can do as well. 

So there is a key difference in business model here. Redhat dishes out
free software