[Toybox] getfattr is insane

[enh]

On Sun, Aug 28, 2016 at 9:40 PM, Rob Landley <rob at landley.net> wrote:
> On 08/20/2016 10:54 PM, enh wrote:
>> On Sat, Aug 20, 2016 at 6:52 PM, Rob Landley <rob at landley.net> wrote:
>>> (Extended attributes make me irritable. They're just so thoroughly NOT
>>> throught through. The querying API puts a gap between "tell me how much
>>> memory to allocate" and the actual query for data, meaning the size can
>>> change between them so you have to LOOP with a realloc, and yet libc
>>> doesn't do this for you.
>>
>> (arguably that's a very unix attitude. or at least BSD. SEE ALSO:
>> readlink(2).
>
> Doing it wrong, or being mad about it done wrong? :)

doing it wrong, and being as likely to copy the things done badly in
the past as the things done well.

> Moore's Law can be phrased as "your hardware depreciates 50% every 18
> months", and way back I noticed a software-side corollary which is 50%
> of what you know about how to program the hardware becomes obsolete
> every 18 months.
>
> The main strength of unix has always been that it's mostly the same 50%
> cycling out over and over. Now that the S-curve of Moore's Law is
> flattening out I'm not sure that's still true, but I'm at least trying
> to establish a unixish baseline on the phone side of things before
> moving on to the next problem.
>
>> at least as we expose these in higher-level languages for
>> the younger generation we can paper over these cracks.
>
> It's not so much "the younger generation" as "there's two orders of
> magnitude more people programming but only one order of magnitude more
> system programmers". Our slice didn't get smaller, the pie got huge. I
> recently read Linus Torvalds estimate there are ten thousand active
> kernel developers who are _public_ about it.
>
> People have been trying to do systems programming in higher-level
> abstractions since multics and the i432. Fuchsia is yet another attempt
> at making microkernels combine with an MMU, because clearly nobody's
> ever tried that before. (Sure the amiga had a mirokernel os that could
> handle multimedia, but what it _didn't_ have was an MMU.)
>
> And yet it turns out no matter how many layers you add you can never
> abstract away the hardware entirely, and somehow breaking up your single
> point of failure into a bunch of vital services always winds up giving
> you _multiple_ single points of failure.
>
> Funny that. But sure, let's have another go.

all i mean is "python and java programmers don't need to know the
kernel api is stupid: they ask once and get a byte sequence back".

>> [he says, while
>> filing a bug in another tab to fix getxattr in the same way we fixed
>> readlink in the android.system.Os API.])
>>
>>> And of course the magic in-band-signaling
>>> prefixes so "setfattr -n walrus filename" is denied, because magic name.)
>>>
>>> Also, the f in setfattr stands for "filesystem". As opposed to...? You'd
>>> think it would be setxattr, but no. There isn't one. Would anyone have
>>> any interest if I MADE one that takes keyword=value pairs to set the
>>> data, prepends "user." by default if you didn't provide a prefix, lets
>>> you set more than one in a given call, and the get version behaves like
>>> a %*(#&%& unix program?
>>>
>>> No?
>>
>> i hate everything about them too, right down to their stupid names.
>> the Mac alternative seemed more sensible from its man page
>> (https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/xattr.1.html)
>> but i've never used it, so i don't know what it's like in practice.
>
> I have a mac laptop (SEI gave me one). I don't use it all that much, but
> I can fire it up and check mac command line stuff.
>
>> i did consider writing something more like that, but i assumed that
>> sooner or later someone would ask for setfattr/getfattr (which are the
>> only Linux tools i've ever come across for this), and didn't want to
>> start the "now we have (n+1) standards" race.
>
> While I'm sympathetic with this point of view, the old one is crap.

yeah, only having scratched the surface before, i didn't realize how
crap until i sat down to reimplement it.

> The tricky part is I've now accepted the old crappy one into toybox, and
> promoted half of it out of pending, and in order to _not_ have two I'd
> either not implement the better way, or have to delete the old one.

although i'm already _building_ them in Android, i haven't actually
added symlinks yet. so not even folks working in master are using
getfattr/setfattr yet.

i think the existing tests cover the interesting cases, so you could
always post the equivalent xattr invocations and their outputs if you
want me to have a go at xattr...

>> and i was wary of adding something supposed to be Mac-like, not having
>> a Mac and so not able to test what interoperability problems i'd be
>> introducing by misreading the man page/hitting gaps in the man page.
>> maybe something for the TODO list though.
>
> I've got one. And I'm willing to accept bug reports from people who
> would notice a difference.
>
> The problem is I don't want to support two commands to do the same thing
> if I can help it. (Unless they share code and one's a trivial reskin of
> the other.)
>
>> [as for the "f" for "filesystem"... the wikipedia page doesn't even
>> understand the difference between POSIX extended attributes and ext2
>> file system attributes. confusion abounds.]
>
> I have _opinions_ about Wikipedia[citation needed].
>
>>> Sigh. The hard part of cleaning this up is figuring out what "clean"
>>> looks like. I promoted the set command already, but this is just... ow.
>>
>> (i think you're forgetting to push again.)
>
> Yeah, I was. Fixed it.
>
> I've now had thismessage sitting open on my desktop for several days
> without actually getting a chance to starting on an xattr program. Sigh.
> Press send already...
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.