DragonFly BSD
DragonFly users List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Dragonflybsd Presentation


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Feb 2005 14:42:09 -0800 (PST)

:
:On Sat, 19 Feb 2005 12:33:10 -0800 (PST), Matthew Dillon
:<dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
:>     slide 3 (threading model)
:> 
:>         Our current threading library is the bastardized 4.x pthreads
:>         library.
:> 
:>         David Xu is currently working on his 1:1 threading library for
:>         DragonFly.  We have implemented fast userland mutexes and are now
:>         working on TLS support.  (I think someone called this N:N before,
:>         but the correct term is 1:1, not N:N).
:> 
:>         The eventual goal is to implement async messaged systems calls
:>         and support an M:N model.
:
:Is it ok to leave it M:Ncpus
    
    M:Ncpus is fine, though N in this case is a 'virtual' number of cpus
    which only happens to usually equal the number of physical cpus.

:>     slide 4 (advantages)
:> 
:>         I would change 'Scales very well' to 'In theory, should scale
:>         very well'.
:
:Can I change it to Architecture advantages instead of advantages?

    Or Architectural advantages.

:...
:> 
:>         * Takes advantage of varsyms and other DragonFly features to
:>           present a source build environment that contains only the
:>           elements required for the build as specified by the package.
:
:You mean we wont support a source based install?

    We would, but it would not be generally used by users.  Source builds are
    fine but they tend to fail for odd reasons far more then binary installs.
    We want to be able to deal with breakage on the build side of things 
    without inconveniencing the user base.

:>     slide 8 (advanced networking stack)
:> 
:>         This code is mostly finished and definitely working.  The
:>         DragonFly per-cpu protocol thread model is intended to allow
:>         MP operation and the code is mostly MP safe, but there is still
:>         a lot of work to do in underlying subsystems before we can actually
:>         turn off the big giant lock.
:
:So I dont have to change anything?

    No.  I'm just giving you some background.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:Thanks
:-- 
:Eduardo Tongson     
:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6033AC66
:$ gpg --recv-keys --keyserver pgp.mit.edu 0x6033AC66
:Key fingerprint : 0A86 79BA 3EC1 4B34 0D65  0E05 F9EC 98A2 6033 AC66




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]