Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Mon, May 11, 2009 at 10:32:30AM -0400, Perry E. Metzger wrote: | The only thing I will directly advocate for (besides scrapping the | current UI) is something like the ssh-agent functionality. It is painful | having to type in your passphrase for every email message you read, | every one you want to sign, etc. gpg (gnupg) version 2 provides "gpg-agent" for this. That may provide some more inspiration for features. pgpM3zJAAMAT1.pgp Description: PGP signature
Re: kern/40969 (Was: commit: src/sys/netkey (key.c:1.175))
On Monday 2009-05-11 11:00 +, Stephen Degler output: :Module Name: src :Committed By: skd :Date: Mon May 11 11:00:51 UTC 2009 : :Modified Files: : src/sys/netkey: key.c : :Log Message: :Fix the sense of two compares. I previously broke this. : :cvs rdiff -u -r1.174 -r1.175 src/sys/netkey/key.c Fixes PR #40969 Regards, Geoff
Re: CVS commit: src/share/man/man4
On Mon, May 11, 2009 at 03:22:29PM +1000, matthew green wrote: > >On Sat, May 09, 2009 at 07:51:41AM -0700, Paul Goyette wrote: >> So really should simply document the option DRM_NO_AGP rather than >> telling folks to include unnecessary drivers! > >Just because it compiles doesn't mean it works properly. For most >drivers at least, you really need the AGP support for the GART. > > > what about systems that don't have AGP? That is part of "most drivers". Some do provide a device-specific mechanism to implement GART, e.g. Radeons do. In some other cases, the system might already provide gart functionality on bridges anyway. But documenting this in any sane way is difficult at best. So the easiest way is likely to just list agp and add a comment that it is possible to skip it with DRM_NO_AGP in some cases. Joerg
re: CVS commit: src/sys/netinet6
>> That said, where we now return EPERM is where in the future we'll >> return the error value returned by kauth(9), like many many other >> places in the kernel. Other parts of the networking stacks (say, >> opening a raw socket) now return EPERM instead of EACCES > > ip(4) and ip6(4) seem to document EACCES. Right. Do you think we need to fix the code or the documentation? i think you should change the code back to how it had been. IMHO - documentation. I like being able to tell when an error comes from kauth(9), and EPERM is a nice way to paint those. i see no good reason for this. kauth is an implementation detail, and shouldn't be changing what the userland interface is looks like unless necessary. ip(4) has been around since netbsd day0 so that is at least 16 years of documentation + code being in sync. .mrg.
Re: CVS commit: src/share/man/man4
On Mon, May 11, 2009 at 03:22:29PM +1000, matthew green wrote: > what about systems that don't have AGP? Or even PCI... Martin
Re: CVS commit: src/sbin/fsck_ffs
"M. Warner Losh" writes: > In message: <87r5yv4rqn@snark.cb.piermont.com> > "Perry E. Metzger" writes: > : > : "M. Warner Losh" writes: > : > What I didn't glean from the discussion is what, exactly, you were > : > going to do about it and what, exactly, you'd like to harmonize with > : > FreeBSD on. It may have been there, but I just missed it. > : > : Documentation. It would involve making all man pages refer consistently > : to FFS, FFSv1, FFSv2, and not to mix in the references to UFS. > > Documentation is easy, and I'll be happy to bring over the changes. Given divergence, it may be more of a question of greping your documentation for variants on "UFS" and fixing them than of bringing over NetBSD changes. > Output of programs and/or input via config file changes is harder... I don't think that there are more than a trivial number of programs that refer directly to ufs in their user interface. However, searching the documentation would also find those (if any). Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/sbin/fsck_ffs
In message: <87r5yv4rqn@snark.cb.piermont.com> "Perry E. Metzger" writes: : : "M. Warner Losh" writes: : > What I didn't glean from the discussion is what, exactly, you were : > going to do about it and what, exactly, you'd like to harmonize with : > FreeBSD on. It may have been there, but I just missed it. : : Documentation. It would involve making all man pages refer consistently : to FFS, FFSv1, FFSv2, and not to mix in the references to UFS. Documentation is easy, and I'll be happy to bring over the changes. Output of programs and/or input via config file changes is harder... I wasn't sure which of these two classes you were asking... Warner
Re: CVS commit: src/sbin/fsck_ffs
"M. Warner Losh" writes: > What I didn't glean from the discussion is what, exactly, you were > going to do about it and what, exactly, you'd like to harmonize with > FreeBSD on. It may have been there, but I just missed it. Documentation. It would involve making all man pages refer consistently to FFS, FFSv1, FFSv2, and not to mix in the references to UFS. Perry -- Perry E. Metzgerpe...@piermont.com
Re: CVS commit: src/sys/arch/i386/i386
On Sat, May 09, 2009 at 06:58:46AM +, Andrew Doran wrote: > > > xen isn't as vulnerable to the LDT/segreg problem as native x86 because > > > it's not MP and doesn't do kernel preemption. For the time being I guess > > > it would suffice to #ifdef the 'cli'. > > > > That's not enough to make the binary run: even with the cli commented > > out the test binary segfaults. > > There may be something else wrong, I'll try to look further. > > > > Any way to use gdb to see what it's doing ? The NetBSD/i386 doesn't want > > to load this executable ... > > Can you ktrace it? At least we then can see if it's hitting the syscall > path. here's what I get: 11703 1 ktrace EMUL "netbsd" 11703 1 ktrace RET ktrace 0 11703 1 ktrace CALL execve(0xbf7ffc27,0xbf7feb68,0xbf7feb70) 11703 1 ktrace NAMI "./architextIndex" 11703 1 architextIndex EMUL "netbsd" 11703 1 architextIndex RET syscall JUSTRETURN 11703 1 architextIndex PSIG SIGSEGV SIG_DFL: code=SEGV_ACCERR, addr=0xacb94, trap=4) 11703 1 architextIndex NAMI "architextIndex.core" -- Manuel Bouyer, LIP6, Universite Paris VI. manuel.bou...@lip6.fr NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
Alistair Crooks writes: > I'll look into providing that somehow (I've been of the opinion that > we need one binary for key management, and one binary for > signing/verification and encrypting/decrypting for a while now - it's > the way that the old nbpg SoC project was going too), and that > definitely gives me an incentive to do that kind of split. The worst part of pgp and gpg have always been the user interfaces -- bulky, so many options you can't remember which ones you want at any given time, complicated init files, etc. I would suggest ignoring any prior precedents on such matters because they're all bad and start from a clean slate. Start fresh as though you were a sane Unix geek building from scratch and produce an interface that is intuitive to Unix users -- if you do, netpgp will take over the world. The only thing I will directly advocate for (besides scrapping the current UI) is something like the ssh-agent functionality. It is painful having to type in your passphrase for every email message you read, every one you want to sign, etc. Perry -- Perry E. Metzgerpe...@piermont.com
