Re: Extended attributes for NFSv3 - possible Linux interop
On Fri, 2 Jul 2010, Robert N. M. Watson wrote:
> Something that's always worried me about the Mac OS X and Linux EA APIs
> is the namespace issue: in FreeBSD, we have an explicit enumeration of
> namespaces reflected in an argument to the system calls -- in our case,
> an int, but you could imagine other options. As I recall, Linux (perhaps
> also IRIX?) designated "system" EAs via an interpretation of names ('$'
> prefix). Mac OS X doesn't do this, or at least, the namespace is
> different. I wonder given the portability concerns: would it make sense
> to make the NFS wire protocol identify the namespace explicitly, and
> then OSes can map to/from their local implementation semantics? Linux
> could strip the '$' before putting the name on the wire and select the
> system namespace in the RPC, whereas FreeBSD could map its local notion
> of EXTATTR_NAMESPACE_SYSTEM into whatever the NFS constant is. Then when
> it pops out the other end, mapping back to local semantics would occur.
> This seems more likely to get the security right (in FreeBSD, writing to
> the system namespace requires a specific privilege in our privilege
> system), and is an adequate superset of all the APIs to be useful.
[added the Linux maintainers]
In my current implementation, the server only provides storage for EAs,
and never interprets them. Otherwise, security becomes very difficult
and possibly not viable with such a basic general approach (i.e. a side
simple protocol). The separate NFSv4 Labeled NFS effort is an example of
how to go beyond simple sever storage.
At Trond's suggestion, I've implemented a special sever namespace in the
Linux code, where all client EAs are stored, so:
system.foo on the client is transmitted over the wire as such, and then
the server stores the EA in nfsd.system.foo.
This is done transparently to the client, and the nfsd. namespace is
privileged on the server, and also never interpreted by the server.
I'd suggest generalizing this for a specification, to allow for a variety
of possible server implementations (including where the server does not
even support EAs locally itself).
> I'm happy to help contribute to the writing on an Internet Draft and/or
> RFC -- the lack of NFS support for EAs (and the EA vs. file fork
> confusion) have long caused me frustration, and with systems like
> SELinux, our various MAC policies, and all sorts of other things
> floating around, there's a strong motivation to fix this ... in a
> portable way! I'm just sorry I haven't gotten to this sooner...
The IETF process is closed for NFSv3, so in this case, it would be not an
ID or RFC.
> Could we set up a phone call to chat about all this? Things are really
> busy here this summer, both for good and bad reasons, but a phone call
> on East Coast time is usually arrangeable for me (I'm mostly on British
> time).
I'm in Sydney, btw.
We could set up a call with potential stake-holders.
> Any chance you might be at USENIX Security in DC this August?
No, but I will be in Boston for LinuxCon approx. 9th-12th August.
--
James Morris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Extended attributes for NFSv3 - possible Linux interop
On 5 Jul 2010, at 10:25, James Morris wrote: >> I'm happy to help contribute to the writing on an Internet Draft and/or >> RFC -- the lack of NFS support for EAs (and the EA vs. file fork >> confusion) have long caused me frustration, and with systems like >> SELinux, our various MAC policies, and all sorts of other things >> floating around, there's a strong motivation to fix this ... in a >> portable way! I'm just sorry I haven't gotten to this sooner... > > The IETF process is closed for NFSv3, so in this case, it would be not an > ID or RFC. From a working group, yes, but a third-party informational RFC might fit the process? It's been about a decade since I've done anything in IETF-land so I'm not familiar with how the process has evolved. However, there used to be a way to feed "this is a best practice originating outside the IETF with protocol implications" ID through the RFC system, which leaves it "not a standard" but at least a useful reference in an authoritative form. Robert___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Using lex in a shared library
Not related to your problem, but related to $SUBJECT: make sure to use -P in LFLAGS so your lex-generated symbols don't conflict with those present in applications that use your library, or in other libraries those applications may use. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Do we still need libc_r and libkse in /usr/src/lib?
Hi Hackers, I've just started learning implementation of threads in FreeBSD-CURRENT. exctags found three different implementations of pthread_create function - libc_r, libkse and libthr: # pri kind tag file 1 F f_pthread_create lib/libc_r/uthread/uthread_create.c _pthread_create(pthread_t *thread, const pthread_attr_t *attr, 2 F f_pthread_create lib/libkse/thread/thr_create.c _pthread_create(pthread_t * thread, const pthread_attr_t * attr, 3 F f_pthread_create lib/libthr/thread/thr_create.c _pthread_create(pthread_t * thread, const pthread_attr_t * attr, I did a quick search in the google and found that libc_r (N:1 model) and libkse (N:M model) are no longer used in FreeBSD. So the only supported implementation of POSIX threads API is libthr (1:1 model), right? However, I found that both libc_r and libkse are still in /usr/src/lib. That looks like a bug because you even cannot build these libraries (I encountered compilation errors). I don't see obvious reason to keep such a dead code. Isn't it better to remove these libraries (of course you can still access the source code since SVN doesn't really delete anything)? If not, could you please explain why? Thanks! -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmi...@gmail.com skype: krivenok_dmitry jabber: krivenok_dmi...@jabber.ru icq: 242-526-443 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: elf obj load: skip zero-sized sections early
on 02/07/2010 11:29 Bjoern A. Zeeb said the following: > On Fri, 25 Jun 2010, Andriy Gapon wrote: > > Hey, > >> Proposed patch skips zero sized sections without going into trouble of >> allocating section entry (progtab), doing zero-sized memory allocs and >> copies. >> I observe that sometimes zero-sized set_pcpu sections are produced in >> module >> objects, maybe when a module doesn't create any per cpu data of its >> one, but >> references external pcpu data. Not sure. [snip] >> This work is based on np@'s investigation and original patch: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html >> > > Have you guys figured this out already? By 'this' - do you mean why that zero-sized section is produced at all? Does it really matter why that happens? I stated my guess already. Now I see that it is enough to simply include sys/pcpu.h for this to happen. Inline assembly at the start of the said header unconditionally creates the section. If DPCPU_DEFINE is never used in a module, then set_pcpu section remains empty. Neither compiler nor linker have any reason to drop empty sections in the build process for amd64 modules. I am not sure if ".section set_pcpu" assembly can be made conditional or moved some place else, so that the section is only created when DPCPU_DEFINE is actually used. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: elf obj load: skip zero-sized sections early
On Mon, 5 Jul 2010, Andriy Gapon wrote: on 02/07/2010 11:29 Bjoern A. Zeeb said the following: On Fri, 25 Jun 2010, Andriy Gapon wrote: Hey, Proposed patch skips zero sized sections without going into trouble of allocating section entry (progtab), doing zero-sized memory allocs and copies. I observe that sometimes zero-sized set_pcpu sections are produced in module objects, maybe when a module doesn't create any per cpu data of its one, but references external pcpu data. Not sure. [snip] This work is based on np@'s investigation and original patch: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html Have you guys figured this out already? By 'this' - do you mean why that zero-sized section is produced at all? Does it really matter why that happens? Well, no, I was thinking of the workaround and going ahead to commit somehting;) I stated my guess already. Now I see that it is enough to simply include sys/pcpu.h for this to happen. Inline assembly at the start of the said header unconditionally creates the section. If DPCPU_DEFINE is never used in a module, then set_pcpu section remains empty. Neither compiler nor linker have any reason to drop empty sections in the build process for amd64 modules. I am not sure if ".section set_pcpu" assembly can be made conditional or moved some place else, so that the section is only created when DPCPU_DEFINE is actually used. The same applies to VIMAGE btw. Same technique. /bz -- Bjoern A. ZeebFrom August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: elf obj load: skip zero-sized sections early
on 05/07/2010 20:12 Bjoern A. Zeeb said the following: > On Mon, 5 Jul 2010, Andriy Gapon wrote: > >> on 02/07/2010 11:29 Bjoern A. Zeeb said the following: >>> On Fri, 25 Jun 2010, Andriy Gapon wrote: >>> >>> Hey, >>> Proposed patch skips zero sized sections without going into trouble of allocating section entry (progtab), doing zero-sized memory allocs and copies. I observe that sometimes zero-sized set_pcpu sections are produced in module objects, maybe when a module doesn't create any per cpu data of its one, but references external pcpu data. Not sure. >> [snip] This work is based on np@'s investigation and original patch: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html >>> >>> Have you guys figured this out already? >> >> By 'this' - do you mean why that zero-sized section is produced at all? >> Does it really matter why that happens? > > Well, no, I was thinking of the workaround and going ahead to commit > somehting;) Preview? :-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: elf obj load: skip zero-sized sections early
On 7/5/10 10:12 AM, Bjoern A. Zeeb wrote: On Mon, 5 Jul 2010, Andriy Gapon wrote: [...] The same applies to VIMAGE btw. Same technique. or the proposed per-vimage AND per-CPU zone (to allow pcpu stats in a vimage..).. which degenerates to just more pcpu stuff if vimage is not enabled. /bz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Non-POSIX compliant pmake with secondary expansion?
Hi Garret, On Wed, 30 Jun 2010, Garrett Cooper wrote: GC>I currently set: GC> GC>.POSIX= I think this should be actually a target (the first one in the Makefile): .POSIX: GC> GC>In a Makefile thinking that it would enable only POSIX GC>functionality, and was fidgeting around with the Makefile trying to GC>get it to work. In short, I used secondary expansion, it worked, then GC>compared the output from gmake and it failed (because they have the GC>.SECONDEXPANSION keyword). POSIX doesn't mention secondary expansion, GC>so obviously it's not a POSIX feature. GC>So I was wondering if secondary expansion is enabled by default GC>with .POSIX instead of being disabled like it should on pmake? I remember that .POSIX does almost nothing (it switches of auto-makefile-dependency processing, set the %POSIX variable and disables banners for parallel makes). This is because of the way processing works in our make. I had Posix-compatibility of make on my list for some time but dropped it. This would require large rewrites of the code. Even the parser would need to be different because there are subtle differences. harti GC>Thanks, GC>-Garrett GC> GC>$ cat test_Makefile GC>.POSIX= GC> GC>TARGETS= GC> GC>all: $$(TARGETS) GC> GC>TARGETS+=idontexist GC> GC>idontexist: GC> @echo $@ GC>$ make -f test_Makefile all GC>idontexist GC>$ gmake -f test_Makefile GC>gmake: *** No rule to make target `$(TARGETS)', needed by `all'. Stop. GC>$ uname -a GC>FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r206173M: GC>Mon Apr 26 22:45:06 PDT 2010 GC>r...@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata amd64 GC>___ GC>freebsd-hackers@freebsd.org mailing list GC>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers GC>To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" GC> GC> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PCI Express and drivers
On 06/07/2010, at 5:32, Christopher Bowman wrote: > If I could, let me ask another question. My device could potential have up > to 6 BARs, that would be mapped into user space. Should I simply bundle them > together in my driver into one contiguous space or should I make the user > perform multiple mmap calls? If I go the multiple mmap route, how do I match > a mmap call to a particular BAR? Do I use the size of the allocation? Yes, I think you just key off the requested address in the mmap() call. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PCI Express and drivers
If I could, let me ask another question. My device could potential have up to 6 BARs, that would be mapped into user space. Should I simply bundle them together in my driver into one contiguous space or should I make the user perform multiple mmap calls? If I go the multiple mmap route, how do I match a mmap call to a particular BAR? Do I use the size of the allocation? Thanks Christopher On Sat, Jun 26, 2010 at 8:11 AM, Daniel O'Connor wrote: > > On 26/06/2010, at 14:50, Christopher Bowman wrote: > >> PS what board are you using? :) > >> > > Cool, that looks like what I am looking for. I'll go and read up on > it, thanks very much. I am using the Xilinx SP605 > http://www.xilinx.com/products/devkits/EK-S6-SP605-G.htm > > perfect for playing with hardware for a frame buffer device or graphics > device. It comes with a full license for the synthesis and PCIe IP for the > device on that board which is a great deal. > > Ahh, it does look like a fun toy :) > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
