| Message ID | 20230514114930.285147-1-sbabic@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] Makefile: add library for mkfs.btrfs | expand |
On Sun, May 14, 2023 at 01:49:30PM +0200, Stefano Babic wrote: > Even if mkfs.btrfs can be executed from a shell, there are conditions > (see the reasons for the creation of libbtrfsutil) to call a function > inside own applicatiuon code (security, better control, etc.). > > Create a libmkfsbtrfs library with min_mkfs as entry point and the same > syntax like mkfs.btrfs. This can be linked to applications requiring to > create the filesystem. > > Signed-off-by: Stefano Babic <sbabic@denx.de> > --- > > This requires some explanation. Goal is to export mkfs.btrfs as library > to let it be be called from an application. There are use cases in embedded systems > where this is desired and the reasons are exactly the same > that lead to libbtrfsutil. I can shell out mkfs.btrfs, but this is not > the best option (security if shell is compromised, dependency that mkfs is available, > having a self contained application, output format not parsable, etc.). > > For all these reasons, a library that creates a btrfs filesystem is desired. > The patch here just export mkfs.btrfs in the busybox way, that is exports mkfs_main(), > and just builds a library. It does not touch existing code (Makefile). > > Agree that this can be just used by other Open Source projects that are compliant with > GPLv2, but this is exactly my use case :-). > > I would like to know if such as extension can be accepted, even if I know > this is not a topic for most Linux distributions. The use case is reasonable, but creating a separate library is not a good solution IMHO. There needs to be stable versione API, symbol versioning for backward compatibility. If you already link against libbtrfsutil then the mkfs should be provided there. Do you need to create multi device filesystem? Compared to a single device the API would be easier, the one device file descriptor and the flags and numeric parameters like nodesize. The string interface in argc/argv is flexible and extensible but not a real library API. So for a single device we can extract the functions from mkfs and wrap them to a single call. The libbtrfsutil code is sepate so it would need a rewrite and it also has a different license, that's another thing to consider.
Hi David, On 15.05.23 12:59, David Sterba wrote: > On Sun, May 14, 2023 at 01:49:30PM +0200, Stefano Babic wrote: >> Even if mkfs.btrfs can be executed from a shell, there are conditions >> (see the reasons for the creation of libbtrfsutil) to call a function >> inside own applicatiuon code (security, better control, etc.). >> >> Create a libmkfsbtrfs library with min_mkfs as entry point and the same >> syntax like mkfs.btrfs. This can be linked to applications requiring to >> create the filesystem. >> >> Signed-off-by: Stefano Babic <sbabic@denx.de> >> --- >> >> This requires some explanation. Goal is to export mkfs.btrfs as library >> to let it be be called from an application. There are use cases in embedded systems >> where this is desired and the reasons are exactly the same >> that lead to libbtrfsutil. I can shell out mkfs.btrfs, but this is not >> the best option (security if shell is compromised, dependency that mkfs is available, >> having a self contained application, output format not parsable, etc.). >> >> For all these reasons, a library that creates a btrfs filesystem is desired. >> The patch here just export mkfs.btrfs in the busybox way, that is exports mkfs_main(), >> and just builds a library. It does not touch existing code (Makefile). >> >> Agree that this can be just used by other Open Source projects that are compliant with >> GPLv2, but this is exactly my use case :-). >> >> I would like to know if such as extension can be accepted, even if I know >> this is not a topic for most Linux distributions. > > The use case is reasonable, but creating a separate library is not a good > solution IMHO. There needs to be stable versione API, symbol versioning > for backward compatibility. If you already link against libbtrfsutil > then the mkfs should be provided there. Fully agree - it was just to show the use case and reason. If such a call was available in libbtrfsutil, it would be perfect - not only for my use case (a GPLv2 project), but also for application whose sources are not available. > > Do you need to create multi device filesystem? On embedded devices, not. A single device is enough. > Compared to a single > device the API would be easier, the one device file descriptor and the > flags and numeric parameters like nodesize. The string interface in > argc/argv is flexible and extensible but not a real library API. Agree. It is not an API at all. > > So for a single device we can extract the functions from mkfs and wrap > them to a single call. The libbtrfsutil code is sepate so it would need > a rewrite and it also has a different license, that's another thing to > consider. It has a separate license, that is for me just an advantage. But most code in kernel_shared, etc used by mkfs is GPLv2, thet means it should be relicensed or a new implementation should be done to be part of libbtrfsutil. Best regards, Stefano
On 14/05/2023 13.49, Stefano Babic wrote: > Even if mkfs.btrfs can be executed from a shell, there are conditions > (see the reasons for the creation of libbtrfsutil) to call a function > inside own applicatiuon code (security, better control, etc.). > > Create a libmkfsbtrfs library with min_mkfs as entry point and the same Really a minor thing; instead of libmkfsbtrfs, I think that it is better call it libbtrfsmkfs or something like it; so all the btrfs libs are with the same prefix: - libbtrfs - libbtrfsutils - libbtrfsmkfs > syntax like mkfs.btrfs. This can be linked to applications requiring to > create the filesystem. > > Signed-off-by: Stefano Babic <sbabic@denx.de> > --- > [...]
On Mon, May 15, 2023 at 2:05 PM Goffredo Baroncelli <kreijack@libero.it> wrote: > > On 14/05/2023 13.49, Stefano Babic wrote: > > Even if mkfs.btrfs can be executed from a shell, there are conditions > > (see the reasons for the creation of libbtrfsutil) to call a function > > inside own applicatiuon code (security, better control, etc.). > > > > Create a libmkfsbtrfs library with min_mkfs as entry point and the same > > Really a minor thing; instead of libmkfsbtrfs, I think that it is better call it > libbtrfsmkfs or something like it; so all the btrfs libs are with the same prefix: > > - libbtrfs > - libbtrfsutils > - libbtrfsmkfs > I think the idea is that we're *not* going to do that and instead look to expose filesystem creation features in libbtrfsutil.
On 15/05/2023 21.53, Neal Gompa wrote: > On Mon, May 15, 2023 at 2:05 PM Goffredo Baroncelli <kreijack@libero.it> wrote: >> >> On 14/05/2023 13.49, Stefano Babic wrote: >>> Even if mkfs.btrfs can be executed from a shell, there are conditions >>> (see the reasons for the creation of libbtrfsutil) to call a function >>> inside own applicatiuon code (security, better control, etc.). >>> >>> Create a libmkfsbtrfs library with min_mkfs as entry point and the same >> >> Really a minor thing; instead of libmkfsbtrfs, I think that it is better call it >> libbtrfsmkfs or something like it; so all the btrfs libs are with the same prefix: >> >> - libbtrfs >> - libbtrfsutils >> - libbtrfsmkfs >> > > I think the idea is that we're *not* going to do that and instead look > to expose filesystem creation features in libbtrfsutil. > If it is possible, it would be better.
On 15.05.23 21:53, Neal Gompa wrote: > On Mon, May 15, 2023 at 2:05 PM Goffredo Baroncelli <kreijack@libero.it> wrote: >> >> On 14/05/2023 13.49, Stefano Babic wrote: >>> Even if mkfs.btrfs can be executed from a shell, there are conditions >>> (see the reasons for the creation of libbtrfsutil) to call a function >>> inside own applicatiuon code (security, better control, etc.). >>> >>> Create a libmkfsbtrfs library with min_mkfs as entry point and the same >> >> Really a minor thing; instead of libmkfsbtrfs, I think that it is better call it >> libbtrfsmkfs or something like it; so all the btrfs libs are with the same prefix: >> >> - libbtrfs >> - libbtrfsutils >> - libbtrfsmkfs >> > > I think the idea is that we're *not* going to do that and instead look > to expose filesystem creation features in libbtrfsutil. Yes, my patch was just to expose the problem, asking which is the best way to do. Stefano > >
diff --git a/Makefile b/Makefile index 4b0a869b..af71f833 100644 --- a/Makefile +++ b/Makefile @@ -247,12 +247,13 @@ libbtrfsutil_objects = libbtrfsutil/errors.o libbtrfsutil/filesystem.o \ convert_objects = convert/main.o convert/common.o convert/source-fs.o \ convert/source-ext2.o convert/source-reiserfs.o \ mkfs/common.o -mkfs_objects = mkfs/main.o mkfs/common.o mkfs/rootdir.o +mkfs_objects = mkfs/common.o mkfs/rootdir.o +mkfsmain_objects = mkfs/main.o image_objects = image/main.o image/sanitize.o tune_objects = tune/main.o tune/seeding.o tune/change-uuid.o tune/change-metadata-uuid.o \ tune/convert-bgt.o tune/change-csum.o all_objects = $(objects) $(cmds_objects) $(libbtrfs_objects) $(convert_objects) \ - $(mkfs_objects) $(image_objects) $(tune_objects) $(libbtrfsutil_objects) + $(mkfs_objects) $(mkfsmain_objects) $(image_objects) $(tune_objects) $(libbtrfsutil_objects) udev_rules = 64-btrfs-dm.rules 64-btrfs-zoned.rules @@ -320,8 +321,8 @@ MAKEOPTS = --no-print-directory Q=$(Q) progs_box_main = btrfs.o mkfs/main.o image/main.o convert/main.o \ tune/main.o -progs_box_all_objects = $(mkfs_objects) $(image_objects) $(convert_objects) $(tune_objects) -progs_box_all_static_objects = $(static_mkfs_objects) $(static_image_objects) \ +progs_box_all_objects = $(mkfs_objects) $(mkfsmain_objects) $(image_objects) $(convert_objects) $(tune_objects) +progs_box_all_static_objects = $(static_mkfs_objects) $(static_mkfsmain_objects) $(static_image_objects) \ $(static_convert_objects) $(static_tune_objects) progs_box_objects = $(filter-out %/main.o, $(progs_box_all_objects)) \ @@ -396,17 +397,18 @@ static_libbtrfs_objects = $(patsubst %.o, %.static.o, $(shared_objects)) static_libbtrfsutil_objects = $(patsubst %.o, %.static.o, $(libbtrfsutil_objects)) static_convert_objects = $(patsubst %.o, %.static.o, $(convert_objects)) static_mkfs_objects = $(patsubst %.o, %.static.o, $(mkfs_objects)) +static_mkfsmain_objects = $(patsubst %.o, %.static.o, $(mkfsmain_objects)) static_image_objects = $(patsubst %.o, %.static.o, $(image_objects)) static_tune_objects = $(patsubst %.o, %.static.o, $(tune_objects)) -libs_shared = libbtrfs.so.0.1 libbtrfsutil.so.$(libbtrfsutil_version) +libs_shared = libbtrfs.so.0.1 libbtrfsutil.so.$(libbtrfsutil_version) # libmkfsbtrfs.so.0.1 lib_links = libbtrfs.so.0 libbtrfs.so libbtrfsutil.so.$(libbtrfsutil_major) libbtrfsutil.so libs_build = ifeq ($(BUILD_SHARED_LIBRARIES),1) libs_build += $(libs_shared) $(lib_links) endif ifeq ($(BUILD_STATIC_LIBRARIES),1) -libs_build += libbtrfs.a libbtrfsutil.a +libs_build += libbtrfs.a libbtrfsutil.a libmkfsbtrfs.a endif # make C=1 to enable sparse @@ -548,7 +550,7 @@ endif # NOTE: For static compiles, you need to have all the required libs # static equivalent available # -static: $(progs_static) libbtrfs.a libbtrfsutil.a +static: $(progs_static) libbtrfs.a libbtrfsutil.a libmkfsbtrfs.a libbtrfs/version.h: libbtrfs/version.h.in configure.ac @echo " [SH] $@" @@ -577,6 +579,19 @@ libbtrfs.so.0 libbtrfs.so: libbtrfs.so.0.1 libbtrfs/libbtrfs.sym @echo " [LN] $@" $(Q)$(LN_S) -f $< $@ +libmkfsbtrfs.so.0.1: $(mkfs_objects) $(objects) libmkfsbtrfs/libmkfsbtrfs.sym + @echo " [LD] $@" + $(Q)$(CC) $(CFLAGS) $(filter %.o,$^) $(LDFLAGS) $(mkfs_objects) \ + -shared -Wl,-soname,libbtrfs.so.0 -Wl,--version-script=libmkfsbtrfs/libmkfsbtrfs.sym -o $@ + +libmkfsbtrfs.a: $(mkfs_objects) $(objects) mkfs/main.box.o + @echo " [AR] $@" + $(Q)$(AR) cr $@ $^ $(objects) + +libmkfsbtrfs.so.0 libmkfsbtrfs.so: libmkfsbtrfs.so.0.1 libmkfsbtrfs/libmkfsbtrfs.sym + @echo " [LN] $@" + $(Q)$(LN_S) -f $< $@ + libbtrfsutil/%.o: libbtrfsutil/%.c @echo " [CC] $@" $(Q)$(CC) $(LIBBTRFSUTIL_CFLAGS) -o $@ -c $< -o $@ @@ -664,11 +679,11 @@ btrfsck.static: btrfs.static @echo " [LN] $@" $(Q)$(LN_S) -f $^ $@ -mkfs.btrfs: $(mkfs_objects) $(objects) libbtrfsutil.a +mkfs.btrfs: $(mkfs_objects) $(mkfsmain_objects) $(objects) libbtrfsutil.a @echo " [LD] $@" $(Q)$(CC) -o $@ $^ $(LDFLAGS) $(LIBS) -mkfs.btrfs.static: $(static_mkfs_objects) $(static_objects) $(static_libbtrfs_objects) +mkfs.btrfs.static: $(static_mkfs_objects) $(mkfsmain_objects) $(static_objects) $(static_libbtrfs_objects) @echo " [LD] $@" $(Q)$(CC) -o $@ $^ $(STATIC_LDFLAGS) $(STATIC_LIBS)
Even if mkfs.btrfs can be executed from a shell, there are conditions (see the reasons for the creation of libbtrfsutil) to call a function inside own applicatiuon code (security, better control, etc.). Create a libmkfsbtrfs library with min_mkfs as entry point and the same syntax like mkfs.btrfs. This can be linked to applications requiring to create the filesystem. Signed-off-by: Stefano Babic <sbabic@denx.de> --- This requires some explanation. Goal is to export mkfs.btrfs as library to let it be be called from an application. There are use cases in embedded systems where this is desired and the reasons are exactly the same that lead to libbtrfsutil. I can shell out mkfs.btrfs, but this is not the best option (security if shell is compromised, dependency that mkfs is available, having a self contained application, output format not parsable, etc.). For all these reasons, a library that creates a btrfs filesystem is desired. The patch here just export mkfs.btrfs in the busybox way, that is exports mkfs_main(), and just builds a library. It does not touch existing code (Makefile). Agree that this can be just used by other Open Source projects that are compliant with GPLv2, but this is exactly my use case :-). I would like to know if such as extension can be accepted, even if I know this is not a topic for most Linux distributions. Makefile | 33 ++++++++++++++++++++++++--------- 1 file changed, 24 insertions(+), 9 deletions(-) -- 2.34.1