Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.misc > #22743

Re: Unix is dead

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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