From nobody Tue Sep 03 23:07:53 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Wz1WC4wLBz5McqM for ; Tue, 03 Sep 2024 23:08:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wz1WC2z7pz4KwH for ; Tue, 3 Sep 2024 23:08:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2d8f06c2459so1553462a91.0 for ; Tue, 03 Sep 2024 16:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1725404885; x=1726009685; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i0+u7U41NJSQW0Z6f6IQuS14mLczLvosvwzcU7sp3Es=; b=j2K2SY+UlROhqoaJ2TQCJW0do3FTJoCtDfhsdoPAEWW6bVYToCMiVIuOkisj0fSkoL cFWwVx9E+r1xRoQWU4wgAJETPLgUgaDre7Oc8slqhkyK0Lk0pPJ2+CuSsm5iTPGXQ6vP +TumQ9lXxv53pzzc6DaaFjNRBU/tlw8jEjdTzol5oOf1FliBRa7Vkm5Ym+07mu8JRelj WUGEb8CzVceFdABoeKk06As/1mKtJekv3gYCauw9RsVFvLrhAfQkZwRXBw2VfR+atAtc RxkCacANO9YHTXFyxkBF63KSW1EaCZinPknNsAc12hKLdvO2tEJPzRWPd6b5k4uvIiJB XViw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725404885; x=1726009685; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i0+u7U41NJSQW0Z6f6IQuS14mLczLvosvwzcU7sp3Es=; b=quAt4vaeDlTvQZmf8HRUz3FPy6BBzrnL8kJj73jrvjA/SEOeo+QYWOdBzhhAbzpTGc mRpfZdrfNij32xBohZUnobh88ja0MdQMjkjCHv1ye9CRHeULuG2GvN2U6/nQCkLEEdPk yHA5SPgKtjD4czVlj0e7usEjD0+pw9J8ctSu365gv4wsEpq+qjmMPx9D8sL7hbyd0+aN 6Te7lc2tGT1lHFwCPBZNqRpo82hAcxToVbgvGQQNpgBQ5tlWRJPnQkj/z6tAvrSIKewT Tlg8r7IqjgPNbNUtRMrW8aJU0+l36jCUltbSB8JgijIqgGft86KFaL5nF+8+wotqXLsR jMuQ== X-Forwarded-Encrypted: i=1; AJvYcCXb9A2azwj99LzMW0E+aeZlWg8VRD4gjhFgwKq0WhIcm9w3yqartwA7ivpkyxLdew/ZIdT3Kpnf4wZG0EZ+Dts=@freebsd.org X-Gm-Message-State: AOJu0Yyjd02iYTSuHIKBDIghleKgqf7VdJ6K9iu1ycjiqCDSwsTu1Puo Y8rc3chLrUPE04IEzGBv7FrWGEcW4xotOlILuwm66zjZv+yMuNYUf59Gppgzqo9TplxcVyvk/al fKL75XoWYa2W0ernI/wyTgOlepFBnDToeV5JBjvIs1MRrIwL9 X-Google-Smtp-Source: AGHT+IHi1IgnE22SP+PYp4+qUnM/K8gwZjWQtXq9QwKc3fJnndKz80o+EwTl9Z1++q4axTEPQg1pRbttn/fsIGJLQkM= X-Received: by 2002:a17:90b:2889:b0:2d8:94ae:8ae0 with SMTP id 98e67ed59e1d1-2da5581532fmr5780101a91.0.1725404885477; Tue, 03 Sep 2024 16:08:05 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> In-Reply-To: From: Warner Losh Date: Tue, 3 Sep 2024 17:07:53 -0600 Message-ID: Subject: Re: It's not Rust, it's FreeBSD (and LLVM) To: Alan Somers Cc: Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000004b05c506213f21d1" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4Wz1WC2z7pz4KwH --0000000000004b05c506213f21d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 3, 2024 at 2:40=E2=80=AFPM Alan Somers wr= ote: > On Tue, Sep 3, 2024 at 2:21=E2=80=AFPM Warner Losh wrote= : > > > > > > > > On Tue, Sep 3, 2024, 2:19=E2=80=AFPM Alan Somers = wrote: > >> > >> On Tue, Sep 3, 2024 at 1:50=E2=80=AFPM Poul-Henning Kamp > wrote: > >> > > >> > -------- > >> > Alan Somers writes: > >> > > >> > > For example, libifconfig and the /dev/cam/ctl ioctls are both > unstable. > >> > > A port that uses one of those and is built for FreeBSD 14.0 won't > >> > > necessarily work for 14.1. > >> > > >> > Isn't that also a problem today ? > >> > > >> > What difference does it make that src is distributed as a package ? > >> > >> Not "a package" but "many packages". The pkgbase concept builds a > >> separate package for almost every dir under lib, bin, sbin, usr.bin, > >> and usr.sbin. So the problem will be that libifconfig and its > >> consumers will be distributed separately, whereas they are currently > >> distributed together. > > > > > > Won't versions and dependencies solve this? They aren't tied to a kerne= l > version since its a stable ABI. > > > > Warnrr > >> > >> -Alan > > Aren't you the one who just said that the ABI will need to become > stable? Or did you only mean that about the /dev/cam/ctl ioctls? For > private libs, the easiest thing would be if pkgbase could put libs and > their consumers into the same package. But that might not always be > possible. > Generally, you're supposed to update all the packages in the system, which would keep things from getting cross threaded. However, I had thought that 'pkg upgrade libfoo' would upgrade all things that depended on libfoo. However, it doesn't go 'up' the dependency tree, but just 'down' for things that libfoo depends upon. It's one of the fragile things about pkg today used with ports (though often it's totally fine, since the ABIs are usually stable)... I'm not familiar enough with the ctl ioctl to state definitively... However, it appears, at first blush, to be fairly stable though. Warner --0000000000004b05c506213f21d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 3, 2024 at 2:40=E2=80=AFP= M Alan Somers <= asomers@freebsd.org> wrote:
On Tue, Sep 3, 2024 at 2:21=E2=80=AFPM Warner Losh <<= a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com> w= rote:
>
>
>
> On Tue, Sep 3, 2024, 2:19=E2=80=AFPM Alan Somers <asomers@freebsd.org> wrote:<= br> >>
>> On Tue, Sep 3, 2024 at 1:50=E2=80=AFPM Poul-Henning Kamp <phk@phk.freebsd.dk&g= t; wrote:
>> >
>> > --------
>> > Alan Somers writes:
>> >
>> > > For example, libifconfig and the /dev/cam/ctl ioctls are= both unstable.
>> > > A port that uses one of those and is built for FreeBSD 1= 4.0 won't
>> > > necessarily work for 14.1.
>> >
>> > Isn't that also a problem today ?
>> >
>> > What difference does it make that src is distributed as a pac= kage ?
>>
>> Not "a package" but "many packages".=C2=A0 The= pkgbase concept builds a
>> separate package for almost every dir under lib, bin, sbin, usr.bi= n,
>> and usr.sbin.=C2=A0 So the problem will be that libifconfig and it= s
>> consumers will be distributed separately, whereas they are current= ly
>> distributed together.
>
>
> Won't versions and dependencies solve this? They aren't tied t= o a kernel version since its a stable ABI.
>
> Warnrr
>>
>> -Alan

Aren't you the one who just said that the ABI will need to become
stable?=C2=A0 Or did you only mean that about the /dev/cam/ctl ioctls?=C2= =A0 For
private libs, the easiest thing would be if pkgbase could put libs and
their consumers into the same package.=C2=A0 But that might not always be possible.

Generally, you're suppose= d to update all the packages in the system, which would keep
thin= gs from getting cross threaded.

However, I had tho= ught that 'pkg upgrade libfoo' would upgrade all things that depend= ed
on libfoo. However, it doesn't go 'up' the depende= ncy tree, but just 'down' for things that libfoo
depends = upon. It's one of the fragile things about pkg today used with ports (t= hough often
it's totally fine, since the ABIs are usually sta= ble)...

I'm not familiar enough with the ctl i= octl to state definitively... However, it appears, at first blush,
to be fairly stable though.

Warner
--0000000000004b05c506213f21d1--