Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Newsgroups | comp.misc |
| Subject | Re: Unix is dead |
| Date | 2023-03-02 14:03 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <ttqabl$d54$1@reader2.panix.com> (permalink) |
| References | <slrntsdp5q.60h.bencollver@svadhyaya.localdomain> <0001HW.29AFBBB702276F2C70000FCBD38F@news.individual.net> <ttoieu$7tp$1@reader2.panix.com> <wwvilfj4lxu.fsf@LkoBDZeT.terraraq.uk> |
In article <wwvilfj4lxu.fsf@LkoBDZeT.terraraq.uk>, Richard Kettlewell <invalid@invalid.invalid> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> Ian McCall <ian@eruvia.org> wrote: >>> The only reason you'd need to recompile drivers as opposed to install >>> binaries is because of the ABI. It's possible you might -choose- to, >>> but the only reason you'd need to is ABI. >> >> What, exactly, is your definition of "the ABI"? >> >>> This is trivially provable by the fact that every other OS, which has >>> a stable ABI, doesn't require you to compile your drivers but can >>> instead install them as binaries. >> >> You seem to be conflating an "ABI" with the general notion of a >> programming interface. I agree that Linux does not keep the >> latter stable within the kernel, but that is not the same as the >> former. > >You seem to be using ABI to mean little more than calling conventions >and object file formats, which is a very narrow usage of the term, and >certainly not a universal one. Yeah, that's pretty much what an "ABI" is. What you are suggesting amounts to saying that programmers cannot change the order of arguments to a function without violating an ABI; taken to its logical conclusion, any notion of an interface in a compiled language would then form an "ABI", which is ... weird. Particularly if the interface in question is not part of an application (note that the "A" in "ABI" stands for "application"). I am unaware of any sense in which an ABI has ever been generalized to mean the specific details of, say, _function_ signatures and return values of internal interfaces. Perhaps you could share if you know of one? >A long-standing example which goes beyond that would be IBCS, which >specified details for syscalls, structure definitions, etc for an ABI >between a user program and a kernel on an x86 Unix. (I think Linux >suported it at one point, I don't know if it still does and it's barely >relevant any more anyway.) I think you mean, "iBCS" (note the lower-case "i") and the later iBCS2. Too bad implementations had non-standard extensions that lead to incompatibilities. It's almost like it wasn't a very good standard. Broadly, the System V ABI with the processor-specific supplements is equivalent. This perhaps gets to the core of the issue; say the system call interface provided by Linux is considered stable (one of their assurances is to not break userspace by changing it --- at least not without a very, very good reason). But that's entirely separate from an internal programming interface within the kernel, which is what device drivers use. Think of it this way: C11 standardizes a library interface in the form of the C library. The signature of, say, `memcpy` is well-defined. So why can't I compile a bit of code that calls `memcpy` on Windows and link it against Linux's libc? That's the ABI difference. >The Linux kernel's module interface, from the perspective of compiled >code, is an ABI in that broader sense (as well as being an API from the >perspective of source code). Nope, sorry. The Linux kernel module interface is defined to not be stable; what you and the OP are asking for are two separate but related things: a stable interface and a stable ABI to call it with. You get the latter, but not the former. - Dan C.
Back to comp.misc | Previous | Next — Previous in thread | Next in thread | Find similar
Unix is dead Ben Collver <bencollver@tilde.pink> - 2023-01-17 18:15 +0000
Re: Unix is dead Bob Eager <news0009@eager.cx> - 2023-01-17 20:13 +0000
Re: Unix is dead Marco Moock <mo01@posteo.de> - 2023-01-17 21:39 +0100
Re: Unix is dead Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-01-18 04:21 -0500
Re: Unix is dead Marco Moock <mo01@posteo.de> - 2023-01-18 10:58 +0100
Re: Unix is dead Grant Taylor <gtaylor@tnetconsulting.net> - 2023-01-18 22:12 -0700
Re: Unix is dead Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2023-01-18 13:38 +0000
Re: Unix is dead Marco Moock <mo01@posteo.de> - 2023-01-17 21:37 +0100
Re: Unix is dead Sylvia Else <sylvia@email.invalid> - 2023-01-18 11:12 +1100
Re: Unix is dead Y A <air000000000000@ya.ee> - 2023-02-11 08:07 -0800
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-16 09:19 +0000
Re: Unix is dead Grant Taylor <gtaylor@tnetconsulting.net> - 2023-02-16 10:21 -0700
Re: Unix is dead kludge@panix.com (Scott Dorsey) - 2023-02-22 12:55 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-23 09:23 +0000
Re: Unix is dead Eli the Bearded <*@eli.users.panix.com> - 2023-02-23 20:53 +0000
Re: Unix is dead Rich <rich@example.invalid> - 2023-02-23 21:43 +0000
Re: Unix is dead Eli the Bearded <*@eli.users.panix.com> - 2023-02-24 00:06 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-25 16:08 +0000
Re: Unix is dead Eli the Bearded <*@eli.users.panix.com> - 2023-02-26 03:51 +0000
Re: Unix is dead Ben Collver <bencollver@tilde.pink> - 2023-02-26 14:37 +0000
Re: Unix is dead Mike Spencer <mds@bogus.nodomain.nowhere> - 2023-02-26 14:09 -0400
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-26 19:07 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-26 19:12 +0000
Re: Unix is dead kludge@panix.com (Scott Dorsey) - 2023-02-28 02:54 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-28 07:37 +0000
Re: Unix is dead cross@spitfire.i.gajendra.net (Dan Cross) - 2023-02-28 16:59 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-03-01 09:02 +0000
Re: Unix is dead Bob Eager <news0009@eager.cx> - 2023-03-01 09:07 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-03-01 12:11 +0000
Re: Unix is dead Bob Eager <news0009@eager.cx> - 2023-03-01 15:30 +0000
Re: Unix is dead cross@spitfire.i.gajendra.net (Dan Cross) - 2023-03-01 15:01 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-03-01 16:58 +0000
Re: Unix is dead cross@spitfire.i.gajendra.net (Dan Cross) - 2023-03-01 22:09 +0000
Re: Unix is dead Richard Kettlewell <invalid@invalid.invalid> - 2023-03-02 08:06 +0000
Re: Unix is dead cross@spitfire.i.gajendra.net (Dan Cross) - 2023-03-02 14:03 +0000
Re: Unix is dead Richard Kettlewell <invalid@invalid.invalid> - 2023-03-02 14:49 +0000
Re: Unix is dead cross@spitfire.i.gajendra.net (Dan Cross) - 2023-03-02 14:52 +0000
Re: Unix is dead Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2023-02-27 14:04 +0000
Re: Unix is dead Ben Collver <bencollver@tilde.pink> - 2023-02-27 05:26 +0000
Re: Unix is dead kludge@panix.com (Scott Dorsey) - 2023-02-28 02:51 +0000
Re: Unix is dead Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2023-02-27 13:30 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-27 23:24 +0000
Re: Unix is dead Dan Espen <dan1espen@gmail.com> - 2023-02-27 22:41 -0500
Re: Unix is dead kludge@panix.com (Scott Dorsey) - 2023-03-01 19:24 +0000
Re: Unix is dead Dan Espen <dan1espen@gmail.com> - 2023-03-01 15:25 -0500
Re: Unix is dead Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2023-02-28 13:32 +0000
Re: Unix is dead Ian McCall <ian@eruvia.org> - 2023-02-28 13:43 +0000
csiph-web