libflashrom rust binding

[Evan Benn]

Hello flashrom,

I have uploaded 2 CLs implementing a libflashrom rust binding:

https://review.coreboot.org/c/flashrom/+/65280

https://review.coreboot.org/c/flashrom/+/65281

The first creates a bindgen
(https://github.com/rust-lang/rust-bindgen) 'thin' binding generated
from the header.

The second creates a 'fat' binding, translating from more idiomatic
rust into the libflashrom API calls. The fat binding is not complete,
I have added only the parts I am using.

I have also added the first user of the fat binding, flashrom-tester:
https://review.coreboot.org/c/flashrom/+/65282

I think the first question is is the flashrom community happy to have
these bindings live inside the flashrom git repo? They could live in
their own separate repos, but keeping them with flashrom will make
keeping up with libflashrom API changes more straightforward.

Otherwise please review the implementation if you are interested.

Thanks

Evan Benn

[Greg Troxel]

Evan Benn <[e-mail]> writes:
> I think the first question is is the flashrom community happy to have
> these bindings live inside the flashrom git repo? They could live in
> their own separate repos, but keeping them with flashrom will make
> keeping up with libflashrom API changes more straightforward.

I am more or less an outsider, but as a packager:

  I do not want the binding to be hooked into the main build system.

  Building flashrom is one thing, and I expect that to work pretty much
  everywhere.

  Building the rust bindings I expect to be not wanted by everyone who
  wants flashrom, to have heavier dependencies (rustc is beastly), and
  to have signficant portability problems.  That's all fine, but if in
  the same release tarball there should be a way to cd to some subdir,
  and build, expecting that flashrom is already installed and using the
  installed headers and libs, and expecting a rust compiler.

  I don't care at all about upstream repo organization if the rust
  binding is its own release tarball.

  I'll observe that changes to libflashrom and changes to the bindings
  may not be connected.

  Given all of the above, I think it's better to have each language
  binding be a separate repo with separate release tarballs.

[Evan Benn]

On Tue, 19 Jul 2022 at 03:46, Greg Troxel <[e-mail]> wrote:
> Evan Benn <[e-mail]> writes:
> > I think the first question is is the flashrom community happy to have
> > these bindings live inside the flashrom git repo? They could live in
> > their own separate repos, but keeping them with flashrom will make
> > keeping up with libflashrom API changes more straightforward.
>
> I am more or less an outsider, but as a packager:
>
> I do not want the binding to be hooked into the main build system.
>
> Building flashrom is one thing, and I expect that to work pretty much
>   everywhere.

Good point, I will make sure the bindings are not part of the build system.
> Building the rust bindings I expect to be not wanted by everyone who
>   wants flashrom, to have heavier dependencies (rustc is beastly), and
>   to have signficant portability problems.  That's all fine, but if in
>   the same release tarball there should be a way to cd to some subdir,
>   and build, expecting that flashrom is already installed and using the
>   installed headers and libs, and expecting a rust compiler.
>
> I don't care at all about upstream repo organization if the rust
>   binding is its own release tarball.

I agree, the bindings do not need to go in the flashrom tarball.
> I'll observe that changes to libflashrom and changes to the bindings
>   may not be connected.
>
> Given all of the above, I think it's better to have each language
>   binding be a separate repo with separate release tarballs.

I see it is possible to exclude files from the archive using .gitattributes,
but that does not make it easy to publish a libflashrom-rust-bindings
archive separately.

Does anyone know the process or contact for creating a new archive on
review.coreboot.org?

Thanks

[Thomas Heijligen]

Hi Evan, Greg,
sorry for my late response.

I'm fine with having language bindings in the flashrom repository. Especially when a user of those bindings lives also in the repository.
But then we have to find a way to make building everything convenient for developers and distributers.
The other solution would be to create new repositories in gerrit  for the bindings and the user of it. This would imply that we fix our api versioning first. 

Imo the separate repositories in combination with some gerrit bots might be the best solution to make everyone happy. But I'll support you, Evan, on the solution you will choose.

-- Thomas

On 20 July 2022 01:28:34 CEST, Evan Benn <[e-mail]> wrote:
> On Tue, 19 Jul 2022 at 03:46, Greg Troxel <[e-mail]> wrote:
> > Evan Benn <[e-mail]> writes:
> > > I think the first question is is the flashrom community happy to have
> > > these bindings live inside the flashrom git repo? They could live in
> > > their own separate repos, but keeping them with flashrom will make
> > > keeping up with libflashrom API changes more straightforward.
> >
> > I am more or less an outsider, but as a packager:
> >
> > I do not want the binding to be hooked into the main build system.
> >
> > Building flashrom is one thing, and I expect that to work pretty much
> >   everywhere.
>
> Good point, I will make sure the bindings are not part of the build system.
> > Building the rust bindings I expect to be not wanted by everyone who
> >   wants flashrom, to have heavier dependencies (rustc is beastly), and
> >   to have signficant portability problems.  That's all fine, but if in
> >   the same release tarball there should be a way to cd to some subdir,
> >   and build, expecting that flashrom is already installed and using the
> >   installed headers and libs, and expecting a rust compiler.
> >
> > I don't care at all about upstream repo organization if the rust
> >   binding is its own release tarball.
>
> I agree, the bindings do not need to go in the flashrom tarball.
> > I'll observe that changes to libflashrom and changes to the bindings
> >   may not be connected.
> >
> > Given all of the above, I think it's better to have each language
> >   binding be a separate repo with separate release tarballs.
>
> I see it is possible to exclude files from the archive using .gitattributes,
> but that does not make it easy to publish a libflashrom-rust-bindings
> archive separately.
>
> Does anyone know the process or contact for creating a new archive on
> review.coreboot.org?
>
> Thanks
> _______________________________________________
> flashrom mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Felix Singer]

Hi all,

I'm also fine with having this in the flashrom repository. As I
understand it, you are just playing around currently. As long as this
is not hooked up to the build system during this phase (to avoid
problems), I don't see a problem here.

Though, when the plans and ideas get more concrete, then it might make
sense to use a separate repository for it. But let's see where this
goes :)

// Felix


On Sat, 2022-07-30 at 19:24 +0000, Thomas Heijligen wrote:
> Hi Evan, Greg,
> sorry for my late response.
>
> I'm fine with having language bindings in the flashrom repository.
> Especially when a user of those bindings lives also in the
> repository.
> But then we have to find a way to make building everything convenient
> for developers and distributers.
> The other solution would be to create new repositories in gerrit for
> the bindings and the user of it. This would imply that we fix our api
> versioning first.
>
> Imo the separate repositories in combination with some gerrit bots
> might be the best solution to make everyone happy. But I'll support
> you, Evan, on the solution you will choose.
>
> -- Thomas
>
> On 20 July 2022 01:28:34 CEST, Evan Benn <[e-mail]>
> wrote:
> > On Tue, 19 Jul 2022 at 03:46, Greg Troxel <[e-mail]> wrote:
> > >  Evan Benn <[e-mail]> writes:
> > > > I think the first question is is the flashrom community happy
> > > > to have
> > > > these bindings live inside the flashrom git repo? They could
> > > > live in
> > > > their own separate repos, but keeping them with flashrom will
> > > > make
> > > > keeping up with libflashrom API changes more straightforward.
> > >
> > >  I am more or less an outsider, but as a packager:
> > >
> > >    I do not want the binding to be hooked into the main build
> > > system.
> > >
> > >    Building flashrom is one thing, and I expect that to work
> > > pretty much
> > >    everywhere.
> >
> > Good point, I will make sure the bindings are not part of the build
> > system.
> > >    Building the rust bindings I expect to be not wanted by
> > > everyone who
> > >    wants flashrom, to have heavier dependencies (rustc is
> > > beastly), and
> > >    to have signficant portability problems.  That's all fine, but
> > > if in
> > >    the same release tarball there should be a way to cd to some
> > > subdir,
> > >    and build, expecting that flashrom is already installed and
> > > using the
> > >    installed headers and libs, and expecting a rust compiler.
> > >
> > >    I don't care at all about upstream repo organization if the
> > > rust
> > >    binding is its own release tarball.
> >
> > I agree, the bindings do not need to go in the flashrom tarball.
> > >    I'll observe that changes to libflashrom and changes to the
> > > bindings
> > >    may not be connected.
> > >
> > >    Given all of the above, I think it's better to have each
> > > language
> > >    binding be a separate repo with separate release tarballs.
> >
> > I see it is possible to exclude files from the archive using
> > .gitattributes,
> > but that does not make it easy to publish a libflashrom-rust-
> > bindings
> > archive separately.
> >
> > Does anyone know the process or contact for creating a new archive
> > on
> > review.coreboot.org?
> >
> > Thanksflashrom mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> flashrom mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Evan Benn]

On Sun, 31 Jul 2022 at 07:28, Felix Singer <[e-mail]> wrote:
> Hi all,
>
> I'm also fine with having this in the flashrom repository. As I
> understand it, you are just playing around currently. As long as this
> is not hooked up to the build system during this phase (to avoid
> problems), I don't see a problem here.

I do intend to get this submitted soon, and in chromeos we will be using

flashrom_tester -> rust bindings -> libflashrom

to 'AVL' qualify new flash chips for inclusion in chromeos devices.
> Though, when the plans and ideas get more concrete, then it might make
> sense to use a separate repository for it. But let's see where this
> goes :)
>
> // Felix
>
> On Sat, 2022-07-30 at 19:24 +0000, Thomas Heijligen wrote:
> > Hi Evan, Greg,
> > sorry for my late response.
> >
> > I'm fine with having language bindings in the flashrom repository.
> > Especially when a user of those bindings lives also in the
> > repository.
> > But then we have to find a way to make building everything convenient
> > for developers and distributers.
> > The other solution would be to create new repositories in gerrit for
> > the bindings and the user of it. This would imply that we fix our api
> > versioning first.

The API versioning does sound like a big topic, I do prefer to
continue in the same
repo if possible as it does sidestep those issues for now. When a
strong libflashrom
versioning story emerges we can move things around. The rust binding
uses -pre 1.0
versioning to indicate that there is no compatibility between versions.

For packaging I can exclude the rust bindings from the flashrom
tarball, and to make
a rust binding tarball `cargo package` can be used.
> > Imo the separate repositories in combination with some gerrit bots
> > might be the best solution to make everyone happy. But I'll support
> > you, Evan, on the solution you will choose.
> >
> > -- Thomas
> >
> > On 20 July 2022 01:28:34 CEST, Evan Benn <[e-mail]>
> > wrote:
> > > On Tue, 19 Jul 2022 at 03:46, Greg Troxel <[e-mail]> wrote:
> > > > Evan Benn <[e-mail]> writes:
> > > > > I think the first question is is the flashrom community happy
> > > > > to have
> > > > > these bindings live inside the flashrom git repo? They could
> > > > > live in
> > > > > their own separate repos, but keeping them with flashrom will
> > > > > make
> > > > > keeping up with libflashrom API changes more straightforward.
> > > >
> > > > I am more or less an outsider, but as a packager:
> > > >
> > > > I do not want the binding to be hooked into the main build
> > > > system.
> > > >
> > > > Building flashrom is one thing, and I expect that to work
> > > > pretty much
> > > >    everywhere.
> > >
> > > Good point, I will make sure the bindings are not part of the build
> > > system.
> > > > Building the rust bindings I expect to be not wanted by
> > > > everyone who
> > > >    wants flashrom, to have heavier dependencies (rustc is
> > > > beastly), and
> > > >    to have signficant portability problems.  That's all fine, but
> > > > if in
> > > >    the same release tarball there should be a way to cd to some
> > > > subdir,
> > > >    and build, expecting that flashrom is already installed and
> > > > using the
> > > >    installed headers and libs, and expecting a rust compiler.
> > > >
> > > > I don't care at all about upstream repo organization if the
> > > > rust
> > > >    binding is its own release tarball.
> > >
> > > I agree, the bindings do not need to go in the flashrom tarball.
> > > > I'll observe that changes to libflashrom and changes to the
> > > > bindings
> > > >    may not be connected.
> > > >
> > > > Given all of the above, I think it's better to have each
> > > > language
> > > >    binding be a separate repo with separate release tarballs.
> > >
> > > I see it is possible to exclude files from the archive using
> > > .gitattributes,
> > > but that does not make it easy to publish a libflashrom-rust-
> > > bindings
> > > archive separately.
> > >
> > > Does anyone know the process or contact for creating a new archive
> > > on
> > > review.coreboot.org?
> > >
> > > Thanksflashrom mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > flashrom mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Evan Benn]

If there are no other comments I would like to soon push the patches I
have on gerrit as the review is coming to a conclusion:

https://review.coreboot.org/c/flashrom/+/65280
https://review.coreboot.org/c/flashrom/+/65281

These add rust libraries to the

bindings/rust/libflashrom{,-sys}

paths and exclude those from tarball creation.

On Wed, 3 Aug 2022 at 09:49, Evan Benn <[e-mail]> wrote:
> On Sun, 31 Jul 2022 at 07:28, Felix Singer <[e-mail]> wrote:
> > Hi all,
> >
> > I'm also fine with having this in the flashrom repository. As I
> > understand it, you are just playing around currently. As long as this
> > is not hooked up to the build system during this phase (to avoid
> > problems), I don't see a problem here.
>
> I do intend to get this submitted soon, and in chromeos we will be using
>
> flashrom_tester -> rust bindings -> libflashrom
>
> to 'AVL' qualify new flash chips for inclusion in chromeos devices.
> > Though, when the plans and ideas get more concrete, then it might make
> > sense to use a separate repository for it. But let's see where this
> > goes :)
> >
> > // Felix
> >
> > On Sat, 2022-07-30 at 19:24 +0000, Thomas Heijligen wrote:
> > > Hi Evan, Greg,
> > > sorry for my late response.
> > >
> > > I'm fine with having language bindings in the flashrom repository.
> > > Especially when a user of those bindings lives also in the
> > > repository.
> > > But then we have to find a way to make building everything convenient
> > > for developers and distributers.
> > > The other solution would be to create new repositories in gerrit for
> > > the bindings and the user of it. This would imply that we fix our api
> > > versioning first.
>
> The API versioning does sound like a big topic, I do prefer to
> continue in the same
> repo if possible as it does sidestep those issues for now. When a
> strong libflashrom
> versioning story emerges we can move things around. The rust binding
> uses -pre 1.0
> versioning to indicate that there is no compatibility between versions.
>
> For packaging I can exclude the rust bindings from the flashrom
> tarball, and to make
> a rust binding tarball `cargo package` can be used.
> > > Imo the separate repositories in combination with some gerrit bots
> > > might be the best solution to make everyone happy. But I'll support
> > > you, Evan, on the solution you will choose.
> > >
> > > -- Thomas
> > >
> > > On 20 July 2022 01:28:34 CEST, Evan Benn <[e-mail]>
> > > wrote:
> > > > On Tue, 19 Jul 2022 at 03:46, Greg Troxel <[e-mail]> wrote:
> > > > > Evan Benn <[e-mail]> writes:
> > > > > > I think the first question is is the flashrom community happy
> > > > > > to have
> > > > > > these bindings live inside the flashrom git repo? They could
> > > > > > live in
> > > > > > their own separate repos, but keeping them with flashrom will
> > > > > > make
> > > > > > keeping up with libflashrom API changes more straightforward.
> > > > >
> > > > > I am more or less an outsider, but as a packager:
> > > > >
> > > > > I do not want the binding to be hooked into the main build
> > > > > system.
> > > > >
> > > > > Building flashrom is one thing, and I expect that to work
> > > > > pretty much
> > > > >    everywhere.
> > > >
> > > > Good point, I will make sure the bindings are not part of the build
> > > > system.
> > > > > Building the rust bindings I expect to be not wanted by
> > > > > everyone who
> > > > >    wants flashrom, to have heavier dependencies (rustc is
> > > > > beastly), and
> > > > >    to have signficant portability problems.  That's all fine, but
> > > > > if in
> > > > >    the same release tarball there should be a way to cd to some
> > > > > subdir,
> > > > >    and build, expecting that flashrom is already installed and
> > > > > using the
> > > > >    installed headers and libs, and expecting a rust compiler.
> > > > >
> > > > > I don't care at all about upstream repo organization if the
> > > > > rust
> > > > >    binding is its own release tarball.
> > > >
> > > > I agree, the bindings do not need to go in the flashrom tarball.
> > > > > I'll observe that changes to libflashrom and changes to the
> > > > > bindings
> > > > >    may not be connected.
> > > > >
> > > > > Given all of the above, I think it's better to have each
> > > > > language
> > > > >    binding be a separate repo with separate release tarballs.
> > > >
> > > > I see it is possible to exclude files from the archive using
> > > > .gitattributes,
> > > > but that does not make it easy to publish a libflashrom-rust-
> > > > bindings
> > > > archive separately.
> > > >
> > > > Does anyone know the process or contact for creating a new archive
> > > > on
> > > > review.coreboot.org?
> > > >
> > > > Thanksflashrom mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > >
> > > flashrom mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]