Type abstraction and kernel programming

By: dmcq (dmcq.delete@this.fano.co.uk), July 19, 2021 1:01 am
Room: Moderated Discussions
Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on July 19, 2021 1:03 am wrote:
> FrankHB (frankhb1989.delete@this.gmail.com) on July 17, 2021 1:44 am wrote:
> > Anon (no.delete@this.spam.com) on July 16, 2021 12:01 pm wrote:
> > > FrankHB (frankhb1989.delete@this.gmail.com) on July 16, 2021 6:43 am wrote:
> > > > For example, the abuse of explicitly fixed-width machine
> > > > numbers in the basic type system is totally against
> > > > the abstraction purpose: consider the fact you should not have many chances to have an exactly fixed-with
> > > > integer like "i32" in the real business logic (expect for
> > > > some low-level [de]serialization works between some
> > > > on-wire formats and some in-memory representations), you're routinely making the conversion unconsciously
> > > > to fit the semantic gap between the code and the real design
> > > > implicitly. Such implicity is dangerous before
> > > > you leak "i32" to the design, and then you totally failed
> > > > to abstract details like "32" away. (Rust certainly
> > > > won't insert any check between the gap of "i32" and the_real_type_you_need_in_the_design!)
> > > >
> > > > And compared to exception handling, the typical error handling mechanism in Rust is somehow enforcing
> > > > the designers of API to go against separation of concerns, because the error information is always
> > > > forced explicitly (equally significantly to the non-error "workloads") in the type signature of
> > > > API (also often bad for ABI compatibility, but this is an implementation detail).
> > > >
> > > > Such glitches are often not obvious for most users, making it even more error-prone
> > > > in everyday programming. I don't expect my life easier working with these users.
> > >
> > > I agree here, but in the specific context of "everyday programming", Rust is not a good general purpose
> > > language, for the "everyday" when I just want to make something simple just works I want a GC and proper
> > > exception handling, C++ works better than Rust in this respect but C# works even better.
> > >
> > > Rust is claimed as "system programming" which is a very specific niche, it would be very ankward to use
> > > C# in this niche, C++ have some caveats too, but Rust do very well in this niche, since the topic started
> > > about Linux kernel, I don't think it would be very productive to ignore this specific detail.
> > >
> > I'm glad to see you agree with this, while some Rust fanboys still reject to face
> > the fact and routinely try to replace the use of other languages by Rust blindly.
> >
> > However, "everyday" for a professional programmer may mean he/she does the coding work everyday in a
> > period of the lifecycle of a project, so the restriction of the language applies day to day whatever
> > the domain is. Even in the context of system programming, lacking of the abstraction is not comfortable.
> > But with the limitation of the language, users may forget the reason and tend to compromise, which leads
> > to misinformation to newcomers. This is even occur in some written conventions. The Linux kernel coding
> > style 5)
is a notable example. It says you should "NEVER EVER use a typedef unless you can clearly
> > match one of those rules", which is totally nonsense even in the kernel programming (analysis later).
> > I'm reluctant to get people who follow these dogmas without any doubts in my team.
> >
> >
> > Detail technical points about rule 5):
> >
> > i. Bullet 2. is redundant. The rule itself is not problematic,
> > but hiding of int v. long is not any more special
> > than other types. It is only outstanding to the limitation
> > oflanguages like C for historical reasons (in ISA
> > "native" types) which makes the meaning of types like "long" a mess. It is better to be an example.
> >
> > ii. Bullet c. is vague. What type-checking? Only by the C compiler? Or by any other means?
> >
> > If absolutely any nominal type checks (including manual
> > checks) are allowed, it just render 5) is useless.
> > Ironically, this is exact my position of the problem here: it is up to the designer, not the programmer.
> > If the designer of the components want to say "it is OK to have an nominal (opaque by design) type", it
> > should be here, whether such type is checkable in C. It is an implementation detail that specific language
> > like C cannot utilize this explicit intent to make the code better. (Well, there can be some headache to
> > check the occasional misuses of the type as a non-opaque one in C, but it deserves for C users more or
> > less.) Why bother such details in the convention in a coding style document? The decision of making the
> > type nominally opaque is totally out of the scope of the document, and irrelevant to C.
> >
> > This also renders bullet a. mostly nonsense in practice for the internal interface, because there is no
> > clear standpoint to define "totally" before you draft a standardized convention out of this document.
> >
> > Note the potential abuse is actually not a big deal in C than C++, at least with C
> > you have no chance to try something evil enough like "enable_if_t" to make
> > the not-enough-opaque type "T" made up of "typedef int T;" leaks everywhere.
> >
> > iii. Bullet d. is same to b., and it is even more specific to C. Not
> > saying it is wrong by itself, but combined with c., it is kidding.
> >
> > iv. Bullet e. is seriously wrong. It assumes the userspace having different disciplines to the
> > kernel space. Actually the need of type safety is no different between them, except the fact
> > in kernel you use C almost everywhere, so you must bear some compromised implementation of typechecking.
> > But ironically again, it is the decisions to rely on C makes the case worse: it is C allows
> > such case of lacking of type information to make the meaning of the code clearer (and more possibility
> > to be safer), and the rules in 5) even endorse the bad practice!
> >
> > v. The note in bullet a. is even more misleading. It seems to suggest opaque type is only
> > intend for portability, which is not true. As said, what to make a type nominal is up to
> > the designers, not necessarily to the programmers. The decision of what degrees of opaqueness
> > is also up to the designer's intent of the type. Yes, the "dichotomy" of opaqueness is wrong,
> > and partially opaque types have their own rights to live in the designs.
> >
> > Specifically, consider the hierarchy of standard conformance (like some concrete impl -> XSI ->
> > POSIX -> ISO C), you can't absolutely say something partially specialized in the middle is just
> > nonsense; in many cases, layering is actually an effective way to expose different conforming
> > requirements with few bloats. Such specifications may have partially opaque types to shape the
> > conforming requirements on types. Following the suggestion of bullet a., partially specialized
> > types must have accessors to pretend they are totally opaque in coding. This is absurd.
> >
> >
> > While I think the analysis is quite basic and obvious in the sense of computer science and engineering,
> > some people will not. Consider the fragmentation of int vs. size_t flame war brought by a few
> > notable "int fanboys" like Bjarne Stroustrup and Herb Sutter, as well as the status quo (int
> > is already polluted the design of the standard library, e.g. std::caught_exceptions), I don't
> > think making kernel people happy a necessary task. And as I believe such documentation is not
> > the root source of misinformation, I'm lazy to contribute to change it.
> >
>
> Long explanation, I think the rule is there because in C, pointers to type
> are not compatible even if they point to things which are compatible.
> In short, if someone use an "int" in a library but they typedef'ed it to my_int, and someone else use another
> "int" typedef'ed to their_int, you can use my_int in place of their_int, but not for pointers and you finish
> by adding so many casts from "my_int *" to "their_int *" and the software becomes unreadable.

Why would people stick in their own my_int? Especially if they always have to coerce to their_int? I'd have thought at worst in that case one would have an interface module that had the casts in.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/09 08:56 PM
  Is unsafe hell truly good for linux kernel in the future?Brendan2021/07/09 11:59 PM
    Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 12:37 PM
  Is unsafe hell truly good for linux kernel in the future?anon2021/07/10 03:14 AM
    Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 12:40 PM
      Is unsafe hell truly good for linux kernel in the future?Gabriele Svelto2021/07/10 02:59 PM
        Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 03:42 PM
      Is unsafe hell truly good for linux kernel in the future?anon2021/07/11 05:11 AM
        Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/12 11:40 AM
  Is unsafe hell truly good for linux kernel in the future?Foo_2021/07/10 05:56 AM
    Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 08:59 AM
      Most RWT posters don’t decide what goes into the Linux kernelMark Roulo2021/07/10 11:55 AM
      Is unsafe hell truly good for linux kernel in the future?Foo_2021/07/22 10:10 AM
    Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 09:22 AM
      Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 09:24 AM
        Déja VuDismissive2021/07/10 09:41 AM
          Déja Vucqwrteur2021/07/10 09:47 AM
            Déja VuDismissive2021/07/10 09:51 AM
            Déja VuMichael S2021/07/10 12:11 PM
  Is unsafe hell truly good for linux kernel in the future?Gabriele Svelto2021/07/10 11:51 AM
    Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 12:32 PM
      Is unsafe hell truly good for linux kernel in the future?Michael S2021/07/10 01:04 PM
        Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 01:25 PM
      Is unsafe hell truly good for linux kernel in the future?Gabriele Svelto2021/07/10 02:56 PM
        Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 03:41 PM
          Is unsafe hell truly good for linux kernel in the future?Rayla2021/07/10 04:33 PM
            Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 05:27 PM
              Interesting response... (NT)Rayla2021/07/10 08:02 PM
                perhaps just another lousy AI bot? (NT)anonymou52021/07/10 08:33 PM
                  perhaps just another lousy AI bot?dmcq2021/07/10 10:26 PM
                    perhaps just another lousy AI bot?cqwrteur2021/07/10 10:56 PM
                      perhaps just another lousy AI bot?dmcq2021/07/11 02:29 AM
                      perhaps just another lousy AI bot?anon2021/07/11 05:16 AM
                        perhaps just another lousy AI bot?cqwrteur2021/07/12 02:56 PM
                    perhaps just another lousy AI bot?Rayla2021/07/11 05:13 AM
                      perhaps just another lousy AI bot?cqwrteur2021/07/11 10:59 AM
                        When did I call you a bot, Kebabbert? (NT)Rayla2021/07/11 07:51 PM
              Alternatives?Brendan2021/07/11 12:54 AM
                Alternatives?Michael S2021/07/11 05:01 AM
                  Alternatives?Brendan2021/07/11 05:51 AM
                    Alternatives?cqwrteur2021/07/11 10:58 AM
                      Alternatives?Gabriele Svelto2021/07/12 12:31 AM
                        Alternatives?Michael S2021/07/12 02:58 AM
                          Alternatives?anon22021/07/12 08:08 AM
                            Alternatives?Michael S2021/07/12 08:22 AM
                              cqwrteur: Keep it politeDavid Kanter2021/07/13 07:59 AM
                          Alternatives?dmcq2021/07/12 08:37 AM
                            Alternatives?cqwrteur2021/07/12 03:04 PM
                              Alternatives?dmcq2021/07/12 03:26 PM
                                Alternatives?cqwrteur2021/07/13 12:47 AM
                                  Alternatives?dmcq2021/07/13 05:54 AM
                          Alternatives?Jörn Engel2021/07/13 03:53 PM
                            Alternatives?FrankHB2021/07/17 06:56 AM
                          Differences between Rust and C/GoGabriele Svelto2021/07/14 04:57 AM
                            Differences between Rust and C/GoFrankHB2021/07/17 08:47 AM
                        Alternatives?FrankHB2021/07/12 09:08 AM
                          Alternatives?Gabriele Svelto2021/07/14 01:28 PM
                            Inappropriate messages removed: cqwrteurDavid Kanter2021/07/15 09:59 AM
                            Alternatives?FrankHB2021/07/16 05:43 AM
                              Alternatives?Anon2021/07/16 11:01 AM
                                Alternatives?Gabriele Svelto2021/07/16 12:44 PM
                                Type abstraction and kernel programmingFrankHB2021/07/17 12:44 AM
                                  Type abstraction and kernel programmingdmcq2021/07/18 03:00 AM
                                    Type abstraction and kernel programmingdmcq2021/07/18 03:36 AM
                                  Type abstraction and kernel programmingEtienne Lorrain2021/07/19 12:03 AM
                                    Type abstraction and kernel programmingdmcq2021/07/19 01:01 AM
                                      Type abstraction and kernel programmingAnon2021/07/19 01:05 AM
                                        Type abstraction and kernel programmingdmcq2021/07/19 02:23 AM
                                      Type abstraction and kernel programmingBrendan2021/07/19 06:05 AM
                                Alternatives?gallier22021/07/20 03:57 AM
                                  Alternatives?Anon2021/07/20 05:24 AM
                                    Alternatives?Michael S2021/07/20 09:14 AM
                                      Alternatives?Anon2021/07/20 09:53 AM
                                        Alternatives?gallier22021/07/21 10:44 PM
                                      Alternatives?Adrian2021/07/20 11:00 AM
                                        Alternatives?Brett2021/07/20 10:13 PM
                                          Alternatives?Michael S2021/07/21 01:12 AM
                                            Alternatives?dmcq2021/07/22 11:58 AM
                                          Alternatives?Anon2021/07/21 07:58 AM
                      Alternatives?Brendan2021/07/12 01:34 AM
                        Alternatives?FrankHB2021/07/12 09:57 AM
                          Alternatives?cqwrteur2021/07/12 11:55 AM
                            Alternatives?FrankHB2021/07/12 08:44 PM
                          Alternatives?Brendan2021/07/12 07:52 PM
                            Alternatives?cqwrteur2021/07/12 10:05 PM
                              Alternatives?Anon2021/07/12 10:42 PM
                                Alternatives?cqwrteur2021/07/12 11:42 PM
                                Alternatives?cqwrteur2021/07/12 11:44 PM
                                  Alternatives?Anon2021/07/13 07:32 PM
                                    Alternatives?cqwrteur2021/07/13 08:36 PM
                                    Alternatives?cqwrteur2021/07/13 08:39 PM
                                      Alternatives?Anon2021/07/13 09:02 PM
                                        Alternatives?cqwrteur2021/07/13 09:18 PM
                                    Alternatives?cqwrteur2021/07/13 08:49 PM
                                      Alternatives?Anon2021/07/13 09:07 PM
                                        Alternatives?cqwrteur2021/07/13 09:16 PM
                                          Alternatives?Anon2021/07/13 10:31 PM
                                            Alternatives?cqwrteur2021/07/13 11:30 PM
                                              Alternatives?Anon2021/07/14 12:55 AM
                                                Alternatives?cqwrteur2021/07/14 01:22 AM
                                                  Alternatives?Anon2021/07/14 02:05 AM
                                                    Alternatives?cqwrteur2021/07/14 02:11 AM
                                                      Alternatives?Anon2021/07/14 03:16 AM
                                                        Alternatives?cqwrteur2021/07/14 06:06 AM
                                                          Alternatives?Anon2021/07/14 07:20 AM
                                                            Alternatives?cqwrteur2021/07/14 07:51 AM
                                                              Alternatives?Anon2021/07/14 11:33 AM
                                                              Alternatives?Gabriele Svelto2021/07/14 12:19 PM
                                                                Alternatives?FrankHB2021/07/16 06:07 AM
                                            Alternatives?cqwrteur2021/07/13 11:33 PM
                                              Alternatives?Anon2021/07/14 12:57 AM
                                                Alternatives?cqwrteur2021/07/14 01:21 AM
                                                  Alternatives?dmcq2021/07/14 02:06 AM
                                                    Alternatives?cqwrteur2021/07/14 02:50 AM
                                                  Alternatives?2021/07/15 07:33 AM
                                                    Alternatives?FrankHB2021/07/16 06:13 AM
                                            Alternatives?cqwrteur2021/07/13 11:39 PM
                                              Alternatives?Anon2021/07/14 01:08 AM
                                                Alternatives?cqwrteur2021/07/14 01:20 AM
                                                  Alternatives?dmcq2021/07/14 01:46 AM
                                                    Alternatives?cqwrteur2021/07/14 01:52 AM
                                                      Alternatives?dmcq2021/07/14 09:13 AM
                                                        Alternatives?dmcq2021/07/14 09:23 AM
                                                        Dealing with memory errorsBrendan2021/07/14 11:50 AM
                                                          Dealing with memory errorsdmcq2021/07/14 03:27 PM
                                                            Dealing with memory errorsBrendan2021/07/14 03:55 PM
                                                    Alternatives?cqwrteur2021/07/14 02:12 AM
                                                      Alternatives?Anon2021/07/14 03:16 AM
                                                        Alternatives?cqwrteur2021/07/14 05:55 AM
                                                      Alternatives?FrankHB2021/07/16 06:27 AM
                                                Alternatives?cqwrteur2021/07/14 01:38 AM
                                                  Alternatives?anon2021/07/14 02:50 AM
                                                    Stop feeding that trollnone2021/07/14 03:13 AM
                                                    Alternatives?cqwrteur2021/07/14 06:39 AM
                                                      Alternatives?Brendan2021/07/14 11:15 AM
                                                  Alternatives?Anon2021/07/14 03:19 AM
                                                    Alternatives?cqwrteur2021/07/14 06:12 AM
                                                      Alternatives?Anon2021/07/14 07:17 AM
                                                        Alternatives?cqwrteur2021/07/14 07:47 AM
                                                          Alternatives?Anon2021/07/14 12:00 PM
                                                            Alternatives?cqwrteur2021/07/14 12:44 PM
                                                          Alternatives?2021/07/15 09:36 AM
                                                  Alternatives?Gabriele Svelto2021/07/14 12:26 PM
                                                    Alternatives?cqwrteur2021/07/14 12:46 PM
                                                      Alternatives?Gabriele Svelto2021/07/14 01:36 PM
                                                        Alternatives?cqwrteur2021/07/14 01:55 PM
                                                          Alternatives?Smoochie2021/07/14 11:07 PM
                                                  Alternatives?2021/07/15 07:37 AM
                                                    Alternatives?Brendan2021/07/15 10:21 AM
                                                      Alternatives?Anon2021/07/15 12:15 PM
                                                  Alternatives?FrankHB2021/07/16 06:27 AM
                                          Alternatives?None2021/07/14 01:50 AM
                                            Alternatives?cqwrteur2021/07/14 01:54 AM
                                            Alternatives?cqwrteur2021/07/14 01:55 AM
                                              Alternatives?Rayla2021/07/14 04:47 AM
                                                Alternatives?cqwrteur2021/07/14 05:54 AM
                                              Alternatives?Gabriele Svelto2021/07/14 12:43 PM
                                Alternatives?FrankHB2021/07/12 11:47 PM
                            Alternatives?FrankHB2021/07/12 11:05 PM
                              Alternatives?Michael S2021/07/13 12:01 AM
                                Alternatives?FrankHB2021/07/13 12:25 AM
                            Alternatives?Doug S2021/07/12 11:29 PM
                              Alternatives?cqwrteur2021/07/12 11:48 PM
                              Alternatives?FrankHB2021/07/13 12:07 AM
              Is unsafe hell truly good for linux kernel in the future?2021/07/12 05:27 AM
                Is unsafe hell truly good for linux kernel in the future?Anon2021/07/12 08:46 AM
                Is unsafe hell truly good for linux kernel in the future?Etienne Lorrain2021/07/13 01:00 AM
    Is unsafe hell truly good for linux kernel in the future?cqwrteur2021/07/10 12:38 PM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell avocado?