Re: src.conf(5) seems to affect ports build

2006-10-21 Thread Ruslan Ermilov
On Sat, Oct 21, 2006 at 06:26:35PM +0200, Jeremie Le Hen wrote:
 Hi Ruslan,
 
 On Fri, Oct 20, 2006 at 11:13:32PM +0400, Ruslan Ermilov wrote:
  On Fri, Oct 20, 2006 at 05:08:48PM +0200, Jeremie Le Hen wrote:
   Hi,
   
   src.conf(5) manual page states:
   
   % The src.conf file contains settings that will apply to every build
   % involving the FreeBSD source tree; see build(7).
   % ...
   % The only purpose of src.conf is to control the compilation of the 
   FreeBSD
   % sources, which are usually found in /usr/src.
   
   However, share/mk/bsd.port.mk includes bsd.own.mk which in turn includes
   /etc/src.conf.  Therefore if I have some WITH_/WITHOUT_ knob in it
   which affects CFLAGS, they will be taken into account even for port 
   builds.
   
   Is it the expected behaviour ?  Maybe WITH(OUT)_ should simply avoid
   modifying CFLAGS (though I think this might become useful in the near
   future).
   
  See if the attached patch helps.  If it does, I'll commit.  I've
  never heard back on this patch after I sent it to [EMAIL PROTECTED]
 
 This patch works correctly.  Would you explain me why assigning
 /dev/null to _SRCCONF don't work in the current version of bsd.port.mk ?
 
1) It's spelled SRCCONF.
2) Even if spelled correctly, setting it to /dev/null doesn't prevent
   MK_* variables to be set to their default values:

cd /usr/src  make showconfig SRCCONF=/dev/null

 Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
 order to prevent from polluting the namespace.  If there is to be
 some WITH(OUT)_* knobs which leads to CFLAGS modification in the future
 (I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
 be worth benefiting this framework for ports ?
 
It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put
WITH(OUT)_* in /etc/make.conf it will still be picked up.


Cheers,
-- 
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer


pgpDKhRANkkH4.pgp
Description: PGP signature


Re: src.conf(5) seems to affect ports build

2006-10-21 Thread Jeremie Le Hen
Hi Ruslan,

On Fri, Oct 20, 2006 at 11:13:32PM +0400, Ruslan Ermilov wrote:
 On Fri, Oct 20, 2006 at 05:08:48PM +0200, Jeremie Le Hen wrote:
  Hi,
  
  src.conf(5) manual page states:
  
  % The src.conf file contains settings that will apply to every build
  % involving the FreeBSD source tree; see build(7).
  % ...
  % The only purpose of src.conf is to control the compilation of the FreeBSD
  % sources, which are usually found in /usr/src.
  
  However, share/mk/bsd.port.mk includes bsd.own.mk which in turn includes
  /etc/src.conf.  Therefore if I have some WITH_/WITHOUT_ knob in it
  which affects CFLAGS, they will be taken into account even for port builds.
  
  Is it the expected behaviour ?  Maybe WITH(OUT)_ should simply avoid
  modifying CFLAGS (though I think this might become useful in the near
  future).
  
 See if the attached patch helps.  If it does, I'll commit.  I've
 never heard back on this patch after I sent it to [EMAIL PROTECTED]

This patch works correctly.  Would you explain me why assigning
/dev/null to _SRCCONF don't work in the current version of bsd.port.mk ?

Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
order to prevent from polluting the namespace.  If there is to be
some WITH(OUT)_* knobs which leads to CFLAGS modification in the future
(I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
be worth benefiting this framework for ports ?

Thank you.
Regards,
-- 
Jeremie Le Hen
 jeremie at le-hen dot org  ttz at chchile dot org 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Threading system calls (int 80h)

2006-10-21 Thread Ekkehard Morgenstern
On Monday 16 October 2006 01:12, David Xu wrote:
  How do I use THR syscalls?

 Yes, you can use THR syscalls, they are more simple.
 you can use thr_new to create a thread, and use thr_exit to exit
 a thread.
 You can learn how to use them by reading some code in libthr,
 note, this interfaces are only for thread library implementation,
 it is not advocated to use them in application.

OK, thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Threading system calls (int 80h)

2006-10-21 Thread Ekkehard Morgenstern
On Friday 20 October 2006 23:24, John-Mark Gurney wrote:
 That's why you use rfork_thread(3)...

Thanks! That really helps! :-)

What I'm trying to do is to write a virtual machine in assembly language on 
FreeBSD that can be run right after the kernel has been loaded. I would like 
to avoid external library dependencies, so, for threading, I need some 
mechanism to make it possible with kernel calls only.

I'll be looking at the THR calls as well, but it helps my confidence that 
rfork(2) and rfork_thread(3) are documented.

I'm not sure if I understood the FreeBSD threading mechanism correctly. Are 
threads always processes? Then it would make no difference if I fork instead 
of using specific threading calls. I would like to enable the users of my VM 
to take advantage of multiple CPUs, so a process-based solution doesn't look 
so bad.

How much overhead is involved in FreeBSD multitasking? 
I will probably also implement a virtual threading mechanism, because every VM 
process or thread can also multiplex instruction streams scheduled to run 
concurrently, at least as long as they're interpreted and not converted to 
native code yet. When the number of virtual threads exceeds a configurable 
limit, a real thread or process can be created that can run further virtual 
threads.

Does anyone of you have any further recommendations or advice? I would like to 
pick a solution that can perform optimally on FreeBSD.

- Ekkehard.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]