headers
Xin LI | 3 Oct 2011 03:53

Sharing a file between kernel and userland?


Hi,

Am I understanding correctly that there is currently no way to have a
file that is shared between libkern and libc?  Or is there already a
clean way to do that?

Cheers,
--

-- 
Xin LI <delphij <at> delphij.net>	https://www.delphij.net/
FreeBSD - The Power to Serve!		Live free or die
Permalink | Reply | 1 comment |
headers
mdf | 3 Oct 2011 04:04
Picon
Favicon

Re: Sharing a file between kernel and userland?

> Am I understanding correctly that there is currently no way to have a
> file that is shared between libkern and libc?  Or is there already a
> clean way to do that?

It's currently done with libsbuf -- sys/kern/subr_sbuf.c is built for
the kernel and for lib/libsbuf.  See lib/libsbuf/Makefile.

Cheers,
matthew
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Kutakova Aleksandra | 7 Oct 2011 09:47
Favicon

Gribi pačukstēt Mis Latvijai..

Labs rīts!

Esi tak kaut ko saņēmis info par noslēpumaino Mis Seksīgās kājiņas konkursu? Gadījumā, ja neesi
ticis informēts, nekas!

Tu vari būt drošs, ka lēdijas bija trakoti seksuālas un uzbudinošiem apaļumiem vajadzīgajās
vietās! 

Ja vēlies viņas satikt un apčamdīt...  

ej te: http://immigrazione.roma.it/documenti/pic.php

Borovika Alla

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Josh Paetzel | 8 Oct 2011 11:57
Picon
Favicon

Re: Call to arms: MPSAFE file systems

On 09/12/11 13:08, Robert Watson wrote:
>
> On Sat, 27 Aug 2011, Attilio Rao wrote:
>
>> With the aid of kib and rwatson I made a roughly outlined plan about
>> what is left to do in order to have all the filesystems locked (or
>> eventually dropped) before 10.0) and is summarized here:
>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS
>
> Here's a more succinct summary of the key points from the wiki:
>
> FreeBSD has supported Giant lock-free file systems for years, and
> almost all file systems have been shipping "MPSAFE" for several
> years.  However, VFS retains compatibility support for non-MPSAFE file
> systems.  We want to remove that compatibility support, as it adds
> non-trivial complexity to an already quite complex VFS, simplifying
> the code and making it easier to maintain and enhance.  This means
> either fixing or removing any file systems that can't operate without
> compatibility support.
>
> Attilio has posted a schedule for the removal of compatibility
> crutches, which in turn means removing any un-updated file systems. 
> We are looking for volunteers to perform those updates.  Here's the
> schedule:
>
> 27 August 2011    Attilio posts plan on arch <at> 
> 1 October 2011    Add VFS_GIANT_COMPATIBILITY option (enabled)
> 1 March 2012    Disable VFS_GIANT_COMPATIBILITY option by default
> 1 September 2012    Disconnect non-MPSAFE file systems from build
> 1 March 2013    Garbage collect any un-updated file systems
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian Chadd | 10 Oct 2011 05:04
Picon
Favicon

FreeBSD-10 -> FreeBSD-9.9 ?

Hi all,

Just an idle comment - why don't we just rename FreeBSD-10 to
FreeBSD-9.9 for now, and give the ports/developers some time to "fix"
bad autoconf/automake scripts?
That way -current can still be used for testing/development.

Thanks,

Adrian
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 9 comments |
headers
Adrian Chadd | 16 Oct 2011 03:48
Picon
Favicon

newbus bus access routines and bus_space_barrier()

Hi all,

I'm not clued up on the way of the bus API, so please excuse the
newbie questions.

Nathan and I found that ath(4) wasn't working for a user because of a
missing bus barrier. Ath trips it up because it does lots of loops of
register reads/writes through the bus stream API rather than the
normal bus API.
It does this because it handles the register value swapping in
hardware rather than in software.

The correct fix is to teach ath(4) to use bus_space_barrier() calls
when doing stream calls, which I can do, but the newbus documentation
points out that both normal and stream bus access doesn't enforce
ordering, and barrier calls are needed. But I don't see lots of
bus_space_barrier() calls everywhere. Why's that?

Thanks,

Adrian
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 3 comments |
headers
Warner Losh | 16 Oct 2011 05:45

Re: newbus bus access routines and bus_space_barrier()

Usually they are needed, but we get away without them often because they are needed in a limited set of
circumstances and we have memory barriers in our locking primitives.

Warner

On Oct 15, 2011, at 7:48 PM, Adrian Chadd wrote:

> Hi all,
> 
> I'm not clued up on the way of the bus API, so please excuse the
> newbie questions.
> 
> Nathan and I found that ath(4) wasn't working for a user because of a
> missing bus barrier. Ath trips it up because it does lots of loops of
> register reads/writes through the bus stream API rather than the
> normal bus API.
> It does this because it handles the register value swapping in
> hardware rather than in software.
> 
> The correct fix is to teach ath(4) to use bus_space_barrier() calls
> when doing stream calls, which I can do, but the newbus documentation
> points out that both normal and stream bus access doesn't enforce
> ordering, and barrier calls are needed. But I don't see lots of
> bus_space_barrier() calls everywhere. Why's that?
> 
> Thanks,
> 
> 
> Adrian
> _______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adrian Chadd | 16 Oct 2011 06:39
Picon
Favicon

Re: newbus bus access routines and bus_space_barrier()

On 16 October 2011 11:45, Warner Losh <imp <at> bsdimp.com> wrote:
> Usually they are needed, but we get away without them often because they are needed in a limited set of
circumstances and we have memory barriers in our locking primitives.

Right. I'll just change the ath driver register ops to enforce a
read/write barrier on each read or write.
It'd be nice to teach the driver and the HAL about "correct" barriers
but I just don't have the time. :(

(FYI: apparently linux's ioread32/iowrite32 operations enforce
barriers on each op.)

Adrian
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Adrian Chadd | 16 Oct 2011 18:20
Picon
Favicon

Re: newbus bus access routines and bus_space_barrier()

On 16 October 2011 11:45, Warner Losh <imp <at> bsdimp.com> wrote:
> Usually they are needed, but we get away without them often because they are needed in a limited set of
circumstances and we have memory barriers in our locking primitives.

Hm, so should this actively be fixed for drivers? I note iwn(4) does
its own (correct looking?) barrier stuff. A few other drivers do. ath
doesn't (yet).
wi(4) doesn't yet do barriers, but someone supplied a patch that may
work better on ppc if said barriers are included.

Thanks,

Adrian
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
'Drive a New BMW for R4999 P/M' | 19 Oct 2011 01:26
Picon

Drive A New BMW for R4999 P/M


                                 wowbmw.com

                   Drive a new BMW from R4999 per month!

     Can't see the pictures? [1]Click here to view this email online. 

                       Save up to R1 411.54 per month
                              [2]BMW E90 320i 
                        BMW E90 320i Petrol (Manual)
     * From R4 999.00 per month.
     * Manual
     * 2.0L Petrol
     * Radio/CD
     * Aircon Climate Control
     * Central Locking
     * ABS/ASC + T&CBC
     * Fog Lamps
     * Cruise Control
     * Alloy Wheels
     * Isofix
     * Multifunction Steering Wheel
     * Cruise Control
     * Run Flat Tyres
     * 5 Year / 100 000km Motorplan

                            Are you Interested?
                              [3]YES  /  [4]NO

                       Save up to R1 463.76 per month
(Continue reading)

Permalink | Reply | 0 comments |

Gmane