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
Evan Benn evanbenn@chromium.org 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.
On Tue, 19 Jul 2022 at 03:46, Greg Troxel gdt@lexort.com wrote:
Evan Benn evanbenn@chromium.org 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
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 evanbenn@chromium.org wrote:
On Tue, 19 Jul 2022 at 03:46, Greg Troxel gdt@lexort.com wrote:
Evan Benn evanbenn@chromium.org 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 -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
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 evanbenn@chromium.org wrote:
On Tue, 19 Jul 2022 at 03:46, Greg Troxel gdt@lexort.com wrote:
Evan Benn evanbenn@chromium.org 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 -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
On Sun, 31 Jul 2022 at 07:28, Felix Singer felixsinger@posteo.net 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 evanbenn@chromium.org wrote:
On Tue, 19 Jul 2022 at 03:46, Greg Troxel gdt@lexort.com wrote:
Evan Benn evanbenn@chromium.org 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 -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
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 evanbenn@chromium.org wrote:
On Sun, 31 Jul 2022 at 07:28, Felix Singer felixsinger@posteo.net 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 evanbenn@chromium.org wrote:
On Tue, 19 Jul 2022 at 03:46, Greg Troxel gdt@lexort.com wrote:
Evan Benn evanbenn@chromium.org 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 -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
-
Evan Benn -
Felix Singer -
Greg Troxel -
Thomas Heijligen