Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Dec 1998 22:23:34 -0500 (EST)
From:      Brian Feldman <green@unixhelp.org>
To:        Julian Elischer <julian@whistle.com>
Cc:        Mike Smith <mike@smith.net.au>, "Richard Seaman, Jr." <lists@tar.com>, Nate Williams <nate@mt.sri.com>, "current@freebsd.org" <current@FreeBSD.ORG>
Subject:   Re: Linux Threads patches available
Message-ID:  <Pine.BSF.4.05.9812162217050.19075-100000@janus.syracuse.net>
In-Reply-To: <36783B03.446B9B3D@whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Dec 1998, Julian Elischer wrote:

> Mike Smith wrote:
> 
> > 
> > For the sake of reestablishing our compatibility with Linux, I think
> > that your current code should be strongly considered.  As for the

Yay! Something came of my efforts (even if I stopped working on it myself)!

> > eventual fate of threading in the FreeBSD kernel, we're still really
> > dependant on the availibility of development resources here, either in
> > the form of willing and able volunteers or funding which would allow .
> 
> The system patch affects the following files:
> 
> Index: bin/ps/keyword.c
> Index: lib/libc/i386/sys/sigsuspend.S
> Index: sys/i386/linux/linux.h
> Index: sys/i386/linux/linux_dummy.c
> Index: sys/i386/linux/linux_misc.c
> Index: sys/i386/linux/linux_proto.h
> Index: sys/i386/linux/linux_syscall.h
> Index: sys/i386/linux/linux_sysent.c
> Index: sys/i386/linux/linux_sysvec.c
> Index: sys/i386/linux/syscalls.master
> Index: sys/kern/imgact_elf.c
> Index: sys/kern/init_main.c
> Index: sys/kern/kern_exit.c
> Index: sys/kern/kern_fork.c
> Index: sys/kern/kern_sig.c
> Index: sys/sys/proc.h
> Index: sys/sys/signalvar.h
> Index: sys/sys/unistd.h
> Index: sys/sys/user.h
> Index: sys/vm/vm_glue.c
> 
> 
> the sys/i386/linux files are not an issue really.
> 
> the other changes relate to the moving of a couple of fields out 
> of the proc/user structures to a separate sharable entity. vis.

I tried to keep my patches style(9) compliant, make sure your modifications are too :)

> 
> + struct        procsig {
> + #define ps_begincopy ps_sigignore
> +       sigset_t ps_sigignore;  /* Signals being ignored. */
> +       sigset_t ps_sigcatch;   /* Signals being caught by user. */
> +         int      ps_flag;
> +       struct   sigacts ps_sigacts;
> + #define ps_endcopy ps_refcnt
> +       int      ps_refcnt;
> +         int      ps_posix;
> + };            
> +       
> 
> As I said in other mail. This may not be perfect but if we don't 
> make a start on threads, we'll never get to the end.. This seems like
> a fair place to start. I don't see that implimenting it would be
> detrimental to the existing system..
> 
> I would vote for an inclusion to allow others to start experimenting
> with linux-threads based software,
> (note there is now a linux-threads based java JVM.)
> 
> thoughts all?
> 

I don't think it should quite be included yet, because noone's
really thought of the impact of an EXTRA per-process malloc, have
they? If this is alright to give up an extra 4k per process (let's
see, a max-process-count of 100000, this is a total of 400 mb?!?),
then perhaps this should be done. Other than that, I'm not so sure,
because this could be a Very Bad Thing. Has anyone really thought
about the per-process memory overhead issues that come up nowadays
with struct proc growing, and being added to? It seems like to max
out a system, there's at LEAST 800 MB of RAM dedicated to struct
proc and procsig, right?

> julian
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Feldman						  _ __  ___ ___ ___  
 green@unixhelp.org				      _ __ ___ | _ ) __|   \ 
		      http://www.freebsd.org/	 _ __ ___ ____ | _ \__ \ |) |
 FreeBSD: The Power to Serve!		   _ __ ___ ____ _____ |___/___/___/ 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9812162217050.19075-100000>