Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
Peter Memishian writes: The problem is really in the distinction between section two of the man pages (the historical system call interface) and the real OpenSolaris system call interface that dtrace exposes as syscall. Dtrace syscall isn't the same thing as man page section two, as the former is an undocumented implementation detail and the latter is a standard interface. Precisely. Seems like an RFE is warranted to allow the system call names in our manpages to be used. This would eliminate both (a) the current surprise and confusion, and (b) the dependency on the system call implementation details (which are inherently unstable). Another nice side effect would be that the stability level of the probe could match the stability level given in the section two manpage. I mostly agree with that ... I just think that effort is what Adam was referring to as putting lipstick on a pig. My understanding of the rationale is that it's better to have access to a raw, undoctored syscall interface when you really need it, than to have a prettified interface that might not let you see all the details when you want to. In other words, a better answer might be to create an abi provider that maps into the stable programming interface, and leave syscall alone. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
I mostly agree with that ... I just think that effort is what Adam was referring to as putting lipstick on a pig. My understanding of the rationale is that it's better to have access to a raw, undoctored syscall interface when you really need it, than to have a prettified interface that might not let you see all the details when you want to. In other words, a better answer might be to create an abi provider that maps into the stable programming interface, and leave syscall alone. Fair enough. As long as there's some way for someone to write a script that corresponds to the documented system calls without having to rely on implementation artifacts. -- meem ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
Adam Leventhal wrote: On Sat, Feb 02, 2008 at 10:03:33PM -0600, Mike Gerdts wrote: My view of 6590548[1] says that it is closed as not a defect but does not offer any clues as to why it is not a defect. Any chance of getting this cleared up? I'm not sure why we don't include the evaluation in the public version, Because many bug evaluations include references/snippets of the source code, and no one has taken the couple years to sit down and make sure we wouldn't be publishing any bug evaluations containing source code we couldn't open. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
Nicolas Williams writes: On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling wrote: Nicolas Williams [EMAIL PROTECTED] wrote: This pig isn't very attractive. Is a system call number shortage the underlying problem? And is the fix to this ultimately about fixing the syscall number shortage? grouping several syscalls under a single entry is nothting new. I am aware. However, I think, e.g., unlinkat(2) should be just like unlink(2), from a DTrace syscall provider p.o.v. Adam called this a pig for a reason; I agree with that characterization. The problem is really in the distinction between section two of the man pages (the historical system call interface) and the real OpenSolaris system call interface that dtrace exposes as syscall. Dtrace syscall isn't the same thing as man page section two, as the former is an undocumented implementation detail and the latter is a standard interface. I agree that it'd be nice to throw a few bones at the poor user when he does something obvious and still wrong, but I agree that it's just a pig. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
Nicolas Williams [EMAIL PROTECTED] wrote: On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling wrote: Nicolas Williams [EMAIL PROTECTED] wrote: This pig isn't very attractive. Is a system call number shortage the underlying problem? And is the fix to this ultimately about fixing the syscall number shortage? grouping several syscalls under a single entry is nothting new. I am aware. However, I think, e.g., unlinkat(2) should be just like unlink(2), from a DTrace syscall provider p.o.v. Adam called this a pig for a reason; I agree with that characterization. These *at*() calls have been defined in 2001, I would guess this is some time before dtrace came up and truss(1) deals with them ¯A ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
Nicolas Williams [EMAIL PROTECTED] wrote: unlink(2) and unlinkat(2) are different system calls. unlinkat(2) is actually a subcode (number 5) of the SYS_fsat system call. While it might be confusing to u sers, DTrace isn't going to slap lipstack on that particular pig. [...] ---8--- This pig isn't very attractive. Is a system call number shortage the underlying problem? And is the fix to this ultimately about fixing the syscall number shortage? grouping several syscalls under a single entry is nothting new. As long as you stay under the limit of parameters that work fast, I see no problem with this kind of implementation. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
On Sun, Feb 03, 2008 at 01:34:02PM -0800, Adam Leventhal wrote: I'm not sure why we don't include the evaluation in the public version, but here it is: ---8--- Evaluation [ahl 8.9.2007] unlink(2) and unlinkat(2) are different system calls. unlinkat(2) is actually a subcode (number 5) of the SYS_fsat system call. While it might be confusing to u sers, DTrace isn't going to slap lipstack on that particular pig. [...] ---8--- This pig isn't very attractive. Is a system call number shortage the underlying problem? And is the fix to this ultimately about fixing the syscall number shortage? Nico -- ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling wrote: Nicolas Williams [EMAIL PROTECTED] wrote: This pig isn't very attractive. Is a system call number shortage the underlying problem? And is the fix to this ultimately about fixing the syscall number shortage? grouping several syscalls under a single entry is nothting new. I am aware. However, I think, e.g., unlinkat(2) should be just like unlink(2), from a DTrace syscall provider p.o.v. Adam called this a pig for a reason; I agree with that characterization. Nico -- ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
The problem is really in the distinction between section two of the man pages (the historical system call interface) and the real OpenSolaris system call interface that dtrace exposes as syscall. Dtrace syscall isn't the same thing as man page section two, as the former is an undocumented implementation detail and the latter is a standard interface. Precisely. Seems like an RFE is warranted to allow the system call names in our manpages to be used. This would eliminate both (a) the current surprise and confusion, and (b) the dependency on the system call implementation details (which are inherently unstable). Another nice side effect would be that the stability level of the probe could match the stability level given in the section two manpage. -- meem ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
On Feb 1, 2008 12:09 PM, James Carlson [EMAIL PROTECTED] wrote: It's not actually missing. A quick sunsolve search will get you CR 6590548, which explains that fsat is the actual syscall involved. My view of 6590548[1] says that it is closed as not a defect but does not offer any clues as to why it is not a defect. Any chance of getting this cleared up? 1. http://bugs.opensolaris.org/view_bug.do?bug_id=6590548 -- Mike Gerdts http://mgerdts.blogspot.com/ ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
I see that rm(1) uses unlinkat(2), but I don't see a syscall provider probe for unlinkat(2). That's... annoying (but there's always the fbt provider). Actually, I don't see any syscall provider probes for any of the open/unlink/rename/...at[64]() system calls. Is there a CR for this? Nico -- ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?
On Fri, Feb 01, 2008 at 01:09:22PM -0500, James Carlson wrote: Nicolas Williams writes: I see that rm(1) uses unlinkat(2), but I don't see a syscall provider probe for unlinkat(2). That's... annoying (but there's always the fbt provider). Actually, I don't see any syscall provider probes for any of the open/unlink/rename/...at[64]() system calls. Is there a CR for this? It's not actually missing. A quick sunsolve search will get you CR 6590548, which explains that fsat is the actual syscall involved. Ah. Thanks! ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
