linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Krzysztof Błaszkowski" <kb@sysmikro.com.pl>
To: Lennart Poettering <lennart@poettering.net>, NeilBrown <neilb@suse.com>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
	linux-man@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH man-pages] open.2: improve O_PATH documentation.
Date: Thu, 10 Aug 2017 16:02:58 +0200	[thread overview]
Message-ID: <1502373778.9644.27.camel@sysmikro.com.pl> (raw)
In-Reply-To: <20170810102104.GA16888@gardel-login>

Mr Poettering,


I don't know exactly what is the whole discussion about but Mr
consider (very seriously) this regarding C language, C coding,
compilers and program execution:

claim #1: "==" is compare operator another words result is considered
to be true if both arguments are same binary

claim #2: it is possible to compare different types to each other, e.g.
int to char, long long to short

claim #3: if both arguments are of different sizes then compiler
extends shorter type to the size of larger argument padding with 0s.

claim #4: compiler uses type of variable for immediate constant when
comparing the variable to it. thus even bitfields comparisons work.

claim #5: the compiler is modern gcc

thus your whole thesis is damn crap especially your claim like "Linux
is broken". you could write glibc is broken because it does not
"expose" (which is not strictly true) the fsword_t 

Do you know what the term "Linux" stands for ?
I can give you explanation but there are so many other noble developers
which can do this better and it is disappointing that they haven't done
this yet.


I could ignore your email like others did but once upon I gave you a
proof that because systemd-logging can't do better recovery than
underlying file system then doing so by systemd-logging is utterly
stupid, so if you, Mr Poettering, stop doing more userspace crap then
whole "Linux" will only benefit from this.


And the Red Hat should fire you out.
I reckon that fools are the worst plague in the World and that's why I
stopped tolerating fools.
I am a racist - I hate fools.


On Thu, 2017-08-10 at 12:21 +0200, Lennart Poettering wrote:
> On Do, 10.08.17 13:25, NeilBrown (neilb@suse.com) wrote:
> 
> > 
> > +If
> > +.I pathname
> > +refers to an automount point that has not yet been triggered, so
> > no
> > +other filesystem is mounted on it, then the call returns a file
> > +descriptor referring to the automount directory without triggering
> > a mount.
> > +.BR fstatfs (2)
> > +can then be used to determine if it is, in fact, an untriggered
> > +automount point
> > +.RB ( ".f_type == AUTOFS_SUPER_MAGIC" ).
> 
> Because Linux is broken you shouldn't compare f_type just like this,
> and the man page probably shouldn't suggest that either I figure. The
> only safe way is something like this:
> 
>      s.f_type == (typeof(s.f_type)) AUTOFS_SUPER_MAGIC
> 
> That's because f_type is defined with different types (both signed
> and
> unsigned) on different archs, and the magic values tend to use the
> full unsigned 32bit range...
> 
> (Yes, strictly speaking AUTOFS_SUPER_MAGIC isn't one of the unsigned
> 32bit ones, but I think it's better to stick the same rules for all
> magic values comparisons here...)
> 
> (And yes, the statfs() man page only mentions the problem briefly,
> without the typeof way out, but it really should)
> 
> Lennart
> 
-- 
Krzysztof Blaszkowski

  reply	other threads:[~2017-08-10 14:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-10  3:25 [PATCH man-pages] open.2: improve O_PATH documentation NeilBrown
2017-08-10 10:21 ` Lennart Poettering
2017-08-10 14:02   ` Krzysztof Błaszkowski [this message]
2017-08-10 23:04     ` NeilBrown
2017-08-12 20:13       ` Michael Kerrisk (man-pages)
2017-08-10 15:50   ` Matthew Wilcox
2017-08-12 20:11 ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1502373778.9644.27.camel@sysmikro.com.pl \
    --to=kb@sysmikro.com.pl \
    --cc=lennart@poettering.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=neilb@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).