From nobody Tue Jan 17 15:18:43 2023 X-Original-To: freebsd-arch@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 4NxCGT6Cpqz2sYF5 for ; Tue, 17 Jan 2023 15:18:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NxCGT481Dz4JB1 for ; Tue, 17 Jan 2023 15:18:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id v30so45520138edb.9 for ; Tue, 17 Jan 2023 07:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wUDl05KkJ5pw3mhh8z5+ngiMk1qqOUbsL9R7VAAWrFc=; b=y/mn468n9Ys85dxgoggw3kyEE/DKV9QEOZNvrMDmbxIno5Nsv6ZiA/AYS9YYqHiuNf tyHHVJqFQNvYuWlbEcmfKeOkrOX0ROLySy6XhxgqzWN7BI4gYgBwxiPvhZA3W8l4D7CP QnA5+ArgDW8SPKI48B8uuAM2seV2mGhz7h2VWNVCJOKT96MP/jxHWFl1uvq2LOnRLqba lJOFRQP9u9CIhyPdB2AlpNEPuUCy7i54bodTAJ6W0frXr3kYg4082iL90Bxs3gICQvST q6tb7HsEmavOS6DO65yVc33rgLsgri9Fgl54P+cgyFqI3i/eV4sYoqsQmDnrG0kuBiz0 R0ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=wUDl05KkJ5pw3mhh8z5+ngiMk1qqOUbsL9R7VAAWrFc=; b=GUTv8nll5gh4sr7rLBogIgxCNp6UOF118HWl35RgPSeD0tpKS24QAvF2h1BZvat85i LubCjvQ9KBGcT8iWWyuJ821ExxjTJZ6giBYwdsr4ngM0mR3BooO93FXZlDGWwZq5+/3Z Bb4HeF5UsH7vPtjrUhfwOp59u9605Ijnu7s26pcRvS3j6s1yXlG8SMahn1vyu4dkK2JU /D7gB2rrQDLJ4oefWaI/F2UyHLTTQBGL+kDetprs8WB/oJAwJEz+LwPrIYhmIKO1eldV MhmyHxoi28bl2ltXaJdVgnPaI+hDDLGPuTBsl81CR8i6vrr42vmwJEFRlK4Ne6mOiQV8 nTDw== X-Gm-Message-State: AFqh2krxMscD2PeQQhARUPrtwDiZWQzi95rOFzpXRxqjngdJhEf1wc0e p6dzM2E0YwE68Gi9rXhIqjaQWL3+9n5MdRqest5bdpgueZODTQ== X-Google-Smtp-Source: AMrXdXtLEr41KxDOF7vCO9QEr3H/++Whn1JromF7D3+flgHPP0hPOdSLZAb5CjIAVROfOpZKno/5iJxH/74kZoYipSw= X-Received: by 2002:a50:ec82:0:b0:486:ecf1:b6fb with SMTP id e2-20020a50ec82000000b00486ecf1b6fbmr425376edr.48.1673968734942; Tue, 17 Jan 2023 07:18:54 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 17 Jan 2023 08:18:43 -0700 Message-ID: Subject: Re: libcamcontrol ? To: Gleb Popov Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cfcbf405f27737d4" X-Rspamd-Queue-Id: 4NxCGT481Dz4JB1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000cfcbf405f27737d4 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 17, 2023 at 2:42 AM Gleb Popov wrote: > I wonder if it makes sense to move some code from > sbin/camcontrol/camcontrol.c to a shared library. Specifically, all > the entry points of the main executable like "devlist", "identify", > etc. and all the code supporting them. > Right now there's a number of routines that are in libcam that implement talking to the drive, but none that interpret the data in any meaningful way, at least in a user userful form. However, the interface to libcam is fairly low level, and assumes the caller takes care of a lot of details, so there's a fair amount of code repetition even within camcontrol. Some additional features in libcam likely could help clean things up for camcontrol as well. I'm not sure where I'd land between putting this in a new library, and having it be just inside of libcam, but leaning towards new library... > I'm asking because I require camcontrol functionality in > sysutils/bsdisks and calling the executable doesn't satisfy my needs. > At the same time, the amount of code I pulled out from camcontrol.c > keeps growing [1] and I feel uncomfortable about it. > I can understand that. we already share some of the nvme info printing code between camcontrol and nvmecontrol. It's a bit of a pain. > Another approach might be implementing libxo in the camcontrol utility > and enriching it to return all the information I need. > I've long wanted this. It would make a lot of scripts that we have at $WORK a lot simpler since we do ad-hoc parsing anyway... This might be an easier path to take, honestly, since it would present this structured data with a good external representation that many could use. I started on this a long time ago, though, and didn't have the time to focus on the schema definition needed to make this work well... > I'm volunteering to do the work, but I need a plan. > I'd lean towards libxo. while there are a number of places in the system that have adopted libxo that are dubious at best, there's several it's been a clear win. camcontrol falls into the clear win category, though it's a combination of a control program and a status reporting program. The control parts won't fit well, imho, but the rest will. Warner --000000000000cfcbf405f27737d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 17, 2023 at 2:42 AM Gleb = Popov <arrowd@freebsd.org> = wrote:
I wonder = if it makes sense to move some code from
sbin/camcontrol/camcontrol.c to a shared library. Specifically, all
the entry points of the main executable like "devlist", "ide= ntify",
etc. and all the code supporting them.

= Right now there's a number of routines that are in libcam that implemen= t talking to the drive, but none that interpret the data in any meaningful = way, at least in a user userful form.

However, the= interface to libcam is fairly low level, and assumes the caller takes care= of a lot of details, so there's a fair amount of code repetition even = within camcontrol. Some additional features in libcam likely could help cle= an things up for camcontrol as well.

I'm not s= ure where I'd land between putting this in a new library, and having it= be just inside of libcam, but leaning towards new library...
=C2= =A0
I'm asking because I require camcontrol functionality in
sysutils/bsdisks and calling the executable doesn't satisfy my needs. At the same time, the amount of code I pulled out from camcontrol.c
keeps growing [1] and I feel uncomfortable about it.
<= br>
I can understand that. we already share some of the nvme info= printing code between camcontrol and nvmecontrol. It's a bit of a pain= .
=C2=A0
Another approach might be implementing libxo in the camcontrol utility
and enriching it to return all the information I need.

I've long wanted this. It would make a lot of scripts t= hat we have at $WORK a lot simpler since we do ad-hoc parsing anyway...

This might be an easier path to take, honestly, since= it would present this structured data with a good external representation = that many could use.

I started on this a long time= ago, though, and didn't have the time to focus on the schema definitio= n needed to make this work well...
=C2=A0
I'm volunteering to do the work, but I need a plan.

I'd lean towards libxo. while there are a number of pl= aces in the system that have adopted libxo that are dubious at best, there&= #39;s several it's been a clear win. camcontrol falls into the clear wi= n category, though it's a combination of a control program and a status= reporting program. The control parts won't fit well, imho, but the res= t will.

=C2=A0Warner
--000000000000cfcbf405f27737d4-- From nobody Thu Feb 16 04:53:43 2023 X-Original-To: freebsd-arch@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 4PHMzF4x9Hz3s4bl for ; Thu, 16 Feb 2023 04:53:45 +0000 (UTC) (envelope-from 01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@amazonses.com) Received: from a8-60.smtp-out.amazonses.com (a8-60.smtp-out.amazonses.com [54.240.8.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PHMzD0k2Tz4T2J for ; Thu, 16 Feb 2023 04:53:44 +0000 (UTC) (envelope-from 01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@amazonses.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tarsnap.com header.s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn header.b=KMqjSXcw; dkim=pass header.d=amazonses.com header.s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw header.b=Kt3W9DzZ; spf=pass (mx1.freebsd.org: domain of 01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@amazonses.com designates 54.240.8.60 as permitted sender) smtp.mailfrom=01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@amazonses.com; dmarc=pass (policy=none) header.from=tarsnap.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn; d=tarsnap.com; t=1676523223; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding; bh=MG39D5Q7qIvfEu54/DROTErSNqQJihCd/lGyQjBZW5Y=; b=KMqjSXcws6zCDewuR6C3bxmdae4Xv1D2fF1POWMHK132hK3oXpIMcB/B4KtOv0uc HA6IY9/0pS/6X5m5opVMswjjOiECBqWwKcIHrhS22rPee5r/RPXgqMyH99R78kycA4K 5bvhAyC3b4h1M+ZcAnLwudEc9+2PaeZLGPAXWLxc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1676523223; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=MG39D5Q7qIvfEu54/DROTErSNqQJihCd/lGyQjBZW5Y=; b=Kt3W9DzZxtyr7N95mIC/nFfaKhKR8x7lsN7n6VJcrkGTC4HimLty820vbWOyL2RI PrqJ92oK3vh/yB8zkApz6dLuOrFqALHFO6u+iPEH+PmhJFaP/Ic1NcfOuO3rZ/V9jRj v8CqcS14Z1rmjR1qWFaQTRgMv0flCAXYI8GpDoSg= Message-ID: <01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@email.amazonses.com> Date: Thu, 16 Feb 2023 04:53:43 +0000 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-US To: freebsd-arch@freebsd.org From: Colin Percival Subject: RFC: Removing WITHOUT_CAPSICUM and WITHOUT_CASPER from 14.x Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-SES-Outgoing: 2023.02.16-54.240.8.60 X-Spamd-Result: default: False [-1.02 / 15.00]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.83)[-0.826]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; FORGED_SENDER(0.30)[cperciva@tarsnap.com,01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@amazonses.com]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; R_DKIM_ALLOW(-0.20)[tarsnap.com:s=ae7m2yrxjw65l2cqdpjxuucyrvy564tn,amazonses.com:s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:14618, ipnet:54.240.8.0/21, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[54.240.8.60:from]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[cperciva@tarsnap.com,01000186589237d9-6c480554-3d01-405a-9f7a-81e96ae2a395-000000@amazonses.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.240.8.60:from]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[tarsnap.com:+,amazonses.com:+]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[amazonses.com:dkim] X-Rspamd-Queue-Id: 4PHMzD0k2Tz4T2J X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Hi FreeBSD architects, I'd like to remove WITHOUT_CAPSICUM and WITHOUT_CASPER for FreeBSD 14.x. The rationale for this is threefold: 1. They doesn't serve any useful purpose and merely weakens security; 2. They're an anomaly among WITH/WITHOUT options -- most WITHOUT_* options take the form "don't build/install " rather than having effects across the entire tree. 3. They're a pain for release engineering, because approximately nobody ever tests FreeBSD with WITHOUT_CAPSICUM or WITHOUT_CASPER set, but they're the sort of option which can easily break the build due to having affects all over the tree. If nobody objects, my plan is to get rid of the WITHOUT_ build options first and leave MK_{CAPSICUM,CASPER} set unconditionally to "yes"; then sweep the tree (mostly a matter of running unifdef) after 14.x is branched. -- Colin Percival FreeBSD Deputy Release Engineer & EC2 platform maintainer Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid