Type abstraction and kernel programming

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