On Tue, Jul 29, 2025 at 09:50:30AM +0200, Amir Goldstein wrote: > On Tue, Jul 29, 2025 at 7:35 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > On Thu, Jul 24, 2025 at 09:56:16PM +0200, Amir Goldstein wrote: > > > > > Also a bit surprising to see all your lowlevel work and then fuse high > > > > > level coming ;) > > > > > > > > Right now fuse2fs is a high level fuse server, so I hacked whatever I > > > > needed into fuse.c to make it sort of work, awkwardly. That stuff > > > > doesn't need to live forever. > > > > > > > > In the long run, the lowlevel server will probably have better > > > > performance because fuse2fs++ can pass ext2 inode numbers to the kernel > > > > as the nodeids, and libext2fs can look up inodes via nodeid. No more > > > > path construction overhead! > > > > > > > > > > I was wondering how well an LLM would be in the mechanical task of > > > converting fuse2fs to a low level fuse fs, so I was tempted to try. > > > > > > Feel free to use it or lose it or use as a reference, because at least > > > for basic testing it seems to works: > > > https://github.com/amir73il/e2fsprogs/commits/fuse4fs/ > > > > Heh, I'll take a closer look in the morning, but it looks like a > > reasonable conversion. Are you willing to add a "Co-developed-by" tag > > per Sasha's recent proposal[1] if I pull it in? > > > > [1] https://lore.kernel.org/lkml/20250727195802.2222764-1-sashal@xxxxxxxxxx/ > > > > Sure. Added and pushed. > > FYI, some behind the scenes for the interested: > - The commit titles roughly align to the LLM prompts that I used Heh. For reproducibility, I wonder if it ought to be a good idea for the commit messages to contain the prompts fed to the LLM? Maybe I'll suggest that to Sasha. > - One liner commit message "LLM aided conversion" means it's mostly hands off > - Anything other than the one liner commit message suggests human intervention, > that was usually done to make the code more human friendly, the patches > diffstat smaller and frankly, to match my human preferences Oh, I was hoping you'd say that you reprompted all the way to working patches, but I suppose AIs are rather expensive to operate. > - I did not let the agent touch git at all and I took care of applying > fixes into > respective patches manually when needed > - The code compiles, but obviously does not work mid series ha lol :) > - The most interesting part was the last commit of tests, when the agent > was testing and fixing its own conversion. This comes with some nice > observations about machine-human collaboration in this context, for example: > - The machine figured out the need to convert > EXT2_ROOT_INO <=> FUSE_ROOT_INO by itself from self testing, > created the conversion helpers and used them in lookup and some other > methods <nod> I think Miklos mentioned that I could work around that by allowing fuse servers to set the root nodeid with a mount option. > - Obviously, it would have figured out that the conversion helpers need to > be used for all methods sooner or later during self testing, but its self > reflecting cycles can be so long and tedious for an observation that > look so trivial, so a nudge from human "convert all methods" really helps > speeding things up, at least with the agent/model/version that I used Well we could just do the usual "make main exit(1) for the duration of the chur^Wchanges" trick to avoid bisection bombs. :) > I think that language/API conversion is one of the tasks where LLM > can contribute most to humans, as long the work is meticulously > reviewed by a human that has good knowledge of both source and > target language/dialect. Yeah. Though first I need to lay the groundwork by figuring out if macfuse/freebsd fuse actually provide the lowlevel library. If not, then per Ted's direction I'll have to implement both. :/ Maybe I'll try the Oracle codebot this week, though I think they said it only knows Python. Anyway, thanks for the inputs. :) --D > Thanks, > Amir. >
