dtrace discuss - Feb 2008 - 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
--

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.

-- 
James Carlson, Solaris Networking              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

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!

On Feb 1, 2008 12:09 PM, James Carlson <james.d.carlson at sun.com>
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/

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, 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.

# dtrace -c ''rm foo'' -n ''syscall::fsat:entry/pid ==
$target && arg0 == 5/{ print
f("unlinking %s", copyinstr(arg2)); }''
dtrace: description ''syscall::fsat:entry'' matched 1 probe
dtrace: pid 114682 has exited
CPU     ID                    FUNCTION:NAME
  0  76673                       fsat:entry unlinking foo
Entry 1 adam.leventhal [2007-08-09 23:58]

---8<---

Adam

-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

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-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering

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
--

Nicolas Williams <Nicolas.Williams at sun.com> 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:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling
wrote:
> Nicolas Williams <Nicolas.Williams at sun.com> 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
--

Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling wrote:
> > Nicolas Williams <Nicolas.Williams at sun.com> 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

Nicolas Williams writes:
> On Mon, Feb 04, 2008 at 05:44:05PM +0100, Joerg Schilling wrote:
> > Nicolas Williams <Nicolas.Williams at sun.com> 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              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

> 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

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              <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

> 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