On Fri, Oct 25, 2002 at 01:08:30AM +0200, Olivier Péningault wrote:
> le jeu 24-10-2002 à 21:49, Niels Möller a écrit :
>> I.e. when I call socket(), connect() to create a tcp connection, I
>> call some function in -lsocket
> I see what you mean. For the layer 3+ translators, at first I thought
>
le jeu 24-10-2002 à 21:49, Niels Möller a écrit :
> You need one piece of code that links between glibc and your ip
> interfaces, and that also performs packetforwarding, source and
> destination address selection, and such stuff. That code should be
> installed as the translator for /servers/socke
FYI, the linux output is as follows:
$ uname -s
Linux
$ uname -o
GNU/Linux
Thanks,
Jon
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
__
Robert Millan <[EMAIL PROTECTED]> writes:
> According to documentation of BSD Unix [1], the uname command appeared
> in 4.4BSD distribution, and the -s option is suposed to:
Oy, it gets even more confusing. BSD has always used the term
"operating system" to refer to the kernel.
In any case, t
le jeu 24-10-2002 à 09:59, Niels Möller a écrit :
> My advice is that you start by designing and implementing some kind of
> ethernetdevice (kernelspace or part kernel, part userspace translator)
> that can support running several pfinets in parallell. Perhaps it
> should look like the bsd tunnel d
Olivier Péningault <[EMAIL PROTECTED]> writes:
> - A translator per physical device, wich will present the upper side of
> a layer 2 protocol (ex: ethernet protocol over an ethernet card, ppp
> over a serial port, ...)
I think this is the right way, no matter how the servers above this
are design
On Thu, Oct 24, 2002 at 11:05:56AM -0700, Thomas Bushnell, BSG wrote:
> Robert Millan <[EMAIL PROTECTED]> writes:
>
> > According to documentation of BSD Unix [1], the uname command appeared
> > in 4.4BSD distribution, and the -s option is suposed to:
>
> Oy, it gets even more confusing. BSD has
On Thu, Oct 24, 2002 at 04:19:48AM +0200, Vicente Hernando Ara wrote:
> I am changing the Hurd code from cthreads to pthreads.
Goodie.
> * In pfinet code appear __mutex_lock and __mutex_unlock functions,
> instead mutex_lock and so.
> This functions are defined in glibc. Should I change pfinet
On Thu, Oct 24, 2002 at 09:21:54AM +0200, Niels Möller wrote:
> Vicente Hernando Ara <[EMAIL PROTECTED]> writes:
>
> > * This last is an error I get in exec.c file.
> > static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
> > This trigger an error when compiling:
> >exec.c:1382: initializ
On Thu, Oct 24, 2002 at 01:37:36PM +0200, Alfred M. Szmidt wrote:
>
> I have asked on [EMAIL PROTECTED] about why -s should print the
> kernel name instead of the operating system implementation.
thanks. have you pointed them to the archived discussion?:
http://mail.gnu.org/pipermail/bug-hurd/20
I have asked on [EMAIL PROTECTED] about why -s should print the
kernel name instead of the operating system implementation.
--
Alfred M. Szmidt
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Petri Koistinen <[EMAIL PROTECTED]> writes:
>
> > I think uname -s should print: GNUmach.
>
> uname -s prints the kernel, but it's the "kernel" in Unixspeak, that
> is, the thing that interprets the "system calls" where the "system
> calls" are r
On Wed, Oct 23, 2002 at 01:43:08PM -0700, Thomas Bushnell, BSG wrote:
> Petri Koistinen <[EMAIL PROTECTED]> writes:
>
> > I think uname -s should print: GNUmach.
>
> uname -s prints the kernel, but it's the "kernel" in Unixspeak, that
> is, the thing that interprets the "system calls" where the "
On Wed, Oct 23, 2002 at 10:40:46PM +0300, Petri Koistinen wrote:
>
> I don't understand.
There's a bug in Linux, based in the assumption that Linux is not a kernel
but an OS. AFAIK uname asks Linux, the kernel, for the OS name and Linux
says the OS name is "Linux".
The uname maintainers attempte
Olivier Péningault <[EMAIL PROTECTED]> writes:
>le mer 23-10-2002 à 23:33, Niels Möller a écrit :
>> But that's all I've seen. So is anybody actually working on a hurdish
>> networking stack? I've seen no signs of that.
> If nobody works on it, I am volunteer. And if someone does it, I am
> rea
Vicente Hernando Ara <[EMAIL PROTECTED]> writes:
> * This last is an error I get in exec.c file.
> static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
> This trigger an error when compiling:
>exec.c:1382: initializer element is not constant
>
> however:
> pthread_mutex_t lock = PTHR
16 matches
Mail list logo
