Re: Add MKCTF
On Tue, Mar 25, 2014 at 1:47 AM, Christos Zoulas wrote: > In article > , > Ryota Ozaki wrote: >>-=-=-=-=-=- >> >>Hi, >> >>I'm adding a new build variable MKCTF, which >>was discussed on the chat some days ago. >> >>Currently CTF tools are built and used to generate >>and manipulate CTF data of ELF binaries when >>we build with MKDTRACE=yes. Unfortunately, >>current CTF tools don't work on i386/amd64/arm, >>and that adds a burden to try DTrace by users. >> >>The new variable is intended to separate CTF >>stuffs from MKDTRACE; we can build DTrace >>solely without worrying about the CTF issues. >>Fortunately, CTF data are not used yet by >>current DTrace of NetBSD, so DTrace still >>works without CTF data. >> >>Once CTF issues are solved, we would be >>able to merge MKCTF to MKDTRACE again >>but it would not come soon. So I think the >>workaround is still useful at this point. >> >>My patch is attached and also available at >>http://www.netbsd.org/~ozaki-r/MKCTF.diff . > > I am happy with that approach. Thanks! I will commit it later. ozaki-r
Re: Enhance ptyfs to handle multiple instances.
> > You can't find from the driver where the device node file is located > OK, I thought so. Thank you.
Re: Enhance ptyfs to handle multiple instances.
On Mar 24, 5:46pm, net...@izyk.ru (Ilya Zykov) wrote: -- Subject: Re: Enhance ptyfs to handle multiple instances. | Hello! | | Please, tell me know if I wrong. | In general case I can't find(easy), from driver, where its device file located on file system, | its vnode or its directory vnode where this file located. | Such files can be many and I can't find what file used for current operation. | Maybe anybody had being attempted get this info from the driver? You can't find from the driver where the device node file is located in the filesystem, as well as you cannot reliably find from the vnode of the device node the filesystem path. There could be many device nodes that satisfy the criteria (you can make your own tty node with mknod) christos
Re: DIOCDISCARD, fdiscard, and fallocate
On 24 Mar 2014, at 05:01, David Holland wrote:
> ok, I have preliminary patches that kill off DIOCDISCARD and
> DIOCGDISCARDPARAMS in favor of a fdiscard system call (meant to work
> on both files and devices) and add that and also a fallocate system
> call.
>
> http://www.netbsd.org/~dholland/tmp/discard/
> (includes both the 17-part split patch and a combined patch)
> +.\" XXX: if you discard part of a block in a regular file, should that
> +.\" part be explicitly zeroed? Also, how do you find the underlying
> +.\" block size?
For regular files the discarded extent should read back as zeroes
so if we discard part of a block this part should be zeroed.
This is the least surprise for the user of this interface.
What happens for file systems not supporting holes?
Return an error or zero the extent?
> +spec_fdiscard(void *v)
...
> + /* XXX: gross. Is this what we want and is it safe enough? blah */
> + VOP_UNLOCK(vp);
> + mutex_enter(vp->v_interlock);
> + if ((vp->v_iflag & VI_XLOCK) == 0 && vp->v_specnode != NULL) {
> + dev = vp->v_rdev;
> + }
> + mutex_exit(vp->v_interlock);
> + vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
This will now be:
if (vdead_check(vp, VDEAD_NOWAIT) == 0 && vp->v_specnode != NULL)
There is no need to unlock/relock the vnode here.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: Enhance ptyfs to handle multiple instances.
Hello! Please, tell me know if I wrong. In general case I can't find(easy), from driver, where its device file located on file system, its vnode or its directory vnode where this file located. Such files can be many and I can't find what file used for current operation. Maybe anybody had being attempted get this info from the driver? Ilya.
Add MKCTF
Hi, I'm adding a new build variable MKCTF, which was discussed on the chat some days ago. Currently CTF tools are built and used to generate and manipulate CTF data of ELF binaries when we build with MKDTRACE=yes. Unfortunately, current CTF tools don't work on i386/amd64/arm, and that adds a burden to try DTrace by users. The new variable is intended to separate CTF stuffs from MKDTRACE; we can build DTrace solely without worrying about the CTF issues. Fortunately, CTF data are not used yet by current DTrace of NetBSD, so DTrace still works without CTF data. Once CTF issues are solved, we would be able to merge MKCTF to MKDTRACE again but it would not come soon. So I think the workaround is still useful at this point. My patch is attached and also available at http://www.netbsd.org/~ozaki-r/MKCTF.diff . This is the diffstat of the patch: $ diffstat MKCTF.diff distrib/sets/lists/comp/mi |6 +++--- distrib/sets/lists/man/mi| 18 +- etc/Makefile.params |2 +- external/cddl/Makefile |2 +- external/cddl/osnet/lib/Makefile |2 ++ external/cddl/osnet/usr.bin/Makefile |2 +- share/man/man5/mk.conf.5 |7 +++ share/mk/bsd.README |5 + share/mk/bsd.own.mk |4 ++-- share/mk/bsd.prog.mk |2 +- tools/Makefile |2 ++ 11 files changed, 34 insertions(+), 18 deletions(-) Any comments and suggestions are welcome. Best regards, ozaki-r Index: distrib/sets/lists/comp/mi === RCS file: /cvs/cvsroot/src/distrib/sets/lists/comp/mi,v retrieving revision 1.1885 diff -u -r1.1885 mi --- distrib/sets/lists/comp/mi 22 Mar 2014 11:24:35 - 1.1885 +++ distrib/sets/lists/comp/mi 24 Mar 2014 09:43:41 - @@ -20,9 +20,9 @@ ./usr/bin/config comp-util-bin ./usr/bin/crunchgencomp-c-bin ./usr/bin/crunchidecomp-c-bin -./usr/bin/ctfconvert comp-util-bin dtrace -./usr/bin/ctfdump comp-util-bin dtrace -./usr/bin/ctfmerge comp-util-bin dtrace +./usr/bin/ctfconvert comp-util-bin ctf +./usr/bin/ctfdump comp-util-bin ctf +./usr/bin/ctfmerge comp-util-bin ctf ./usr/bin/cvs comp-cvs-bincvs ./usr/bin/cvsbug comp-cvs-bincvs ./usr/bin/elfedit comp-util-bin binutils Index: distrib/sets/lists/man/mi === RCS file: /cvs/cvsroot/src/distrib/sets/lists/man/mi,v retrieving revision 1.1465 diff -u -r1.1465 mi --- distrib/sets/lists/man/mi 19 Mar 2014 15:26:41 - 1.1465 +++ distrib/sets/lists/man/mi 24 Mar 2014 09:43:43 - @@ -125,9 +125,9 @@ ./usr/share/man/cat1/csh.0 man-util-catman .cat ./usr/share/man/cat1/csplit.0 man-util-catman .cat ./usr/share/man/cat1/ctags.0 man-c-catman.cat -./usr/share/man/cat1/ctfconvert.0 man-util-catman .cat,dtrace -./usr/share/man/cat1/ctfdump.0 man-util-catman .cat,dtrace -./usr/share/man/cat1/ctfmerge.0man-util-catman .cat,dtrace +./usr/share/man/cat1/ctfconvert.0 man-util-catman .cat,ctf +./usr/share/man/cat1/ctfdump.0 man-util-catman .cat,ctf +./usr/share/man/cat1/ctfmerge.0man-util-catman .cat,ctf ./usr/share/man/cat1/cu.0 man-util-catman .cat ./usr/share/man/cat1/cut.0 man-util-catman .cat ./usr/share/man/cat1/daicctl.0 man-sysutil-catman .cat @@ -3240,9 +3240,9 @@ ./usr/share/man/html1/csh.html man-util-htmlmanhtml ./usr/share/man/html1/csplit.html man-util-htmlmanhtml ./usr/share/man/html1/ctags.html man-c-htmlman html -./usr/share/man/html1/ctfconvert.html man-util-htmlman html,dtrace -./usr/share/man/html1/ctfdump.html man-util-htmlman html,dtrace -./usr/share/man/html1/ctfmerge.htmlman-util-htmlman html,dtrace +./usr/share/man/html1/ctfconvert.html man-util-htmlmanhtml,ctf +./usr/share/man/html1/ctfdump.html man-util-htmlmanhtml,ctf +./usr/share/man/html1/ctfmerge.htmlman-util-htmlmanhtml,ctf ./usr/share/man/html1/cu.html man-util-htmlmanhtml ./usr/share/man/html1/cut.html man-u
