On Mon, Feb 1, 2021 at 4:21 PM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote:
>
> On 2/1/21 3:49 PM, Amy Parker wrote:
> > Hello filesystem developers!
> >
> > I was scouting through the FreeVXFS code, when I came across this in
> > fs/freevxfs/vxfs.h:
> >
> > enum vxfs_mode {
> > VXFS_ISUID = 0x00000800, /* setuid */
> > VXFS_ISGID = 0x00000400, /* setgid */
> > VXFS_ISVTX = 0x00000200, /* sticky bit */
> > VXFS_IREAD = 0x00000100, /* read */
> > VXFS_IWRITE = 0x00000080, /* write */
> > VXFS_IEXEC = 0x00000040, /* exec */
> >
> > Especially in an expanded form like this, these are ugly to read, and
> > a pain to work with.
> >
> > An example of potentially a better method, from fs/dax.c:
> >
> > #define DAX_SHIFT (4)
> > #define DAX_LOCKED (1UL << 0)
> > #define DAX_PMD (1UL << 1)
> > #define DAX_ZERO_PAGE (1UL << 2)
> > #define DAX_EMPTY (1UL << 3)
> >
> > Pardon the space condensation - my email client is not functioning properly.
>
> That's the gmail web interface, right?
Sadly for now yes. Currently migrating to my own local email system -
just waiting on a domain purchase.
> I believe that you can use a real email client to talk to
> smtp.gmail.com and it won't mangle spaces in your emails.
I've tried - smtp.gmail.com either requires:
- OAuth2: doesn't work for most things
- App passwords: not used by any email client dev with a touch of respect
>
> > Anyways, I believe using bit shifts to represent different file modes
> > would be a much better idea - no runtime penalty as they get
> > calculated into constants at compile time, and significantly easier
> > for the average user to read.
> >
> > Any thoughts on this?
>
> It's all just opinions. :)
Sure, it's just opinions, but this is about making stuff easier to
work with for the average kernel monkey.
>
> I find the hex number list easier to read .. and the values are
Fair, wonder what the average person would think? When trying to help
others understand hex I usually show representations in bitshift form
so they can get the place value nature.
> right there in front of you when debugging, instead of having to
> determine what 1 << 9 is.
Maybe, but it takes barely more time to find the ninth digit of the
hex expression when debugging. Plus, since you're counting the places
in - you're a lot less likely to accidentally select the wrong one
when you're debugging if you're just eyeballing the values.
Perhaps adding a docstring above this with maps of the bitshifts to
their raw hex equivalents set as current could be a good idea?
>
> cheers.
> --
> ~Randy
>
Best regards,
Amy Parker
(she/her/hers)
