Round out kern_descrip.c:file_type_to_name

[rlibby]

Summary

This makes ddb show files more descriptive.

[cem]

sys/kern/kern_descrip.c

3847 ↗

(On Diff #29227)

Maybe "levt"? (We're limited to four characters, right?)

[rlibby]

sys/kern/kern_descrip.c

3847 ↗

(On Diff #29227)

I don't have strong feelings about the actual names so I'm happy to change it to whatever is agreeable.

Yes, four characters according to the db_print_file format (which looks like it currently adds up to 77 chars) ... uh, although, coming back to actually look at the output, it looks like it's already a bit screwed up, probably due to 4-byte vs 8-byte pointers.

db> show files
    File Type     Data     Flag GCFl Count MCount    Vnode  FPID         FCmd
fffff803810a5d10 pipe fffff802b88f98e8 00000003 0000     1      0        0 98244           sh
fffff801631529a0 pipe fffff8024a193460 00000003 0000     2      0        0 98244           sh
fffff801631529a0 pipe fffff8024a193460 00000003 0000     2      0        0 98244           sh
fffff80163152aa8 vnod fffff8004c508ac8 00000001 0000     1      0 fffff8004c508ac8 98244           sh

Looks like we could do more here if there's appetite for more refactoring. I don't think e.g. six characters for the type would kill us.

[rlibby]

sys/kern/kern_descrip.c

3847 ↗

(On Diff #29227)

Here's what that might look like: https://github.com/rlibby/freebsd/commit/4abf39f023b5b735047bf6f6d72fc4952351b955

And example output (amd64). I pasted together a few sections of the output to get a sampling of different types:

db> show files
            File   Type             Data     Flag GCFl Count MCount            Vnode  FPID FCmd
fffff800048e6af0  vnode fffff80004084c00 00000003 0000     6      0 fffff80004f03938   722 zsh
fffff800048e6af0  vnode fffff80004084c00 00000003 0000     6      0 fffff80004f03938   722 zsh
fffff800048e6af0  vnode fffff80004084c00 00000003 0000     6      0 fffff80004f03938   722 zsh
fffff80004920370   pipe fffff8000494fd48 00000003 0000     4      0                0   708 sleep
fffff80004920370   pipe fffff8000494fd48 00000003 0000     4      0                0   708 sleep
fffff80004907e60   pipe fffff8000494fbe0 00000003 0000     2      0                0   707 logger
fffff800048d9820  vnode fffff80003dc9a00 00000003 0000     1      0 fffff800048d6b10   707 logger
fffff80004920d20 socket fffff80004a78368 00000003 0000     1      0                0   321 dhclient
fffff80004920cd0   pipe fffff8000497c8e8 00000003 0000     1      0                0   321 dhclient

[jhb]

I do prefer the updated output. How many chars wide is it?

[rlibby]

In D11061#229517, @jhb wrote:

I do prefer the updated output. How many chars wide is it?

It adds two chars before p_comm.

For 4-byte pointers, it would be 67 up to p_comm.
For 8-byte pointers, it would be 91 up to p_comm.

Because this would also change the %12s (right justified) to %s for p_comm, it will be fewer characters when p_comm is less than 10 characters.

[markj]

If we're spilling over 80 chars anyway, I don't see why shaving 2 chars off the type is helpful, so I prefer the new version. Approved, but perhaps give a couple of days for others to chime in.

[rlibby]

Update patch to widen the ddb show files type field, and adjust
whitespace to line up columns on non-32-bit architectures.

[jhb]

Agreed. If we were still in 80 cols it would be good to not break that, but if we've already lost then oh well.