Re: fstat(1) and sysctl(3)

[Christos Zoulas]

In article <13adfa7f-0d25-9fa0-6559-706e693dc...@gmx.com>,
Kamil Rytarowski   wrote:
>Is there any good reason that fstat(1) needs kvm(3)? Is it viable to
>offer its functionality with sysctl(3), in particular in struct kinfo_file?
>
>I'm have got a use-case (in GDB (*)) where I would make use of more
>fields in struct kinfo_file, at least file path and socket information.
>
>Maybe it would be viable to switch fstat(1) to sysctl(3)?
>
>(*) FreeBSD uses:
>
>fbsd_info_proc_files_entry (kf->kf_type, kf->kf_fd, kf->kf_flags,
>kf->kf_offset, kf->kf_vnode_type,
>kf->kf_sock_domain, kf->kf_sock_type,
>kf->kf_sock_protocol, >kf_sa_local,
>>kf_sa_peer, kf->kf_path);
>

If you do it, make sure you provide info for all the file descriptor types.
(grep -i kvm_read /usr/src/usr.bin/fstat/*.c)

christos

Re: fstat(1) and sysctl(3)

[Simon Burge]

Kamil Rytarowski wrote:

> Is there any good reason that fstat(1) needs kvm(3)? Is it viable to
> offer its functionality with sysctl(3), in particular in struct kinfo_file?

The only reason that fstat wasn't converted to use sysctl way back when
was time/motivation.  I couldn't think of a simple extensible way of
dealing with N file systems and adding N different sysctls meant that it
never got done.

Go for it :)  Good luck.

Cheers,
Simon.

fstat(1) and sysctl(3)

[Kamil Rytarowski]

Is there any good reason that fstat(1) needs kvm(3)? Is it viable to
offer its functionality with sysctl(3), in particular in struct kinfo_file?

I'm have got a use-case (in GDB (*)) where I would make use of more
fields in struct kinfo_file, at least file path and socket information.

Maybe it would be viable to switch fstat(1) to sysctl(3)?

(*) FreeBSD uses:

fbsd_info_proc_files_entry (kf->kf_type, kf->kf_fd, kf->kf_flags,
kf->kf_offset, kf->kf_vnode_type,
kf->kf_sock_domain, kf->kf_sock_type,
kf->kf_sock_protocol, >kf_sa_local,
>kf_sa_peer, kf->kf_path);

-- gdb/fbsd-nat.c