Date: Tue, 17 Jan 2023 08:18:43 -0700 From: Warner Losh <imp@bsdimp.com> To: Gleb Popov <arrowd@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: libcamcontrol ? Message-ID: <CANCZdfra8hCLaqNWxDCD7kNkHqf4ZFaqeY3B0TWSBxkjaMzFCA@mail.gmail.com> In-Reply-To: <CALH631nofBXo935E6xQKB-uMpCi=zykDcccwLfM%2B2=t4KJ2Rxw@mail.gmail.com> References: <CALH631nofBXo935E6xQKB-uMpCi=zykDcccwLfM%2B2=t4KJ2Rxw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000cfcbf405f27737d4 Content-Type: text/plain; charset="UTF-8" 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", "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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 17, 2023 at 2:42 AM Gleb = Popov <<a href=3D"mailto:arrowd@freebsd.org">arrowd@freebsd.org</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I wonder = if it makes sense to move some code from<br> sbin/camcontrol/camcontrol.c to a shared library. Specifically, all<br> the entry points of the main executable like "devlist", "ide= ntify",<br> etc. and all the code supporting them.<br></blockquote><div><br></div><div>= 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.</div><div><br></div><div>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.</div><div><br></div><div>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...</div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I'm asking because I require camcontrol functionality in<br> sysutils/bsdisks and calling the executable doesn't satisfy my needs.<b= r> At the same time, the amount of code I pulled out from camcontrol.c<br> keeps growing [1] and I feel uncomfortable about it.<br></blockquote><div><= br></div><div>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= .</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Another approach might be implementing libxo in the camcontrol utility<br> and enriching it to return all the information I need.<br></blockquote><div= ><br></div><div>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...</di= v><div><br></div><div>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.</div><div><br></div><div>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...</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> I'm volunteering to do the work, but I need a plan.<br></blockquote><di= v><br></div><div>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.</div><div><br></div><div>=C2=A0Warner</div></div></div> --000000000000cfcbf405f27737d4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfra8hCLaqNWxDCD7kNkHqf4ZFaqeY3B0TWSBxkjaMzFCA>