Type abstraction and kernel programming

By: dmcq (dmcq.delete@this.fano.co.uk), July 19, 2021 2: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 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?