dtc/u-boot tool naming, "ftdump", "mkimage"
I just noticed (was told by an affiliate) that the DTC compiler tools shares a tool name "ftdump" with the Freetype project. I was doing a lazy packaging effort to get a few tools around so we can all be running the same version and build some custom kernel RPMs, and this came up.
Wouldn't a better name be "fdtdump", do you think? It's usually not a fun idea to conflict with tools already on the system. A user may run "ftdump" and get the Freetype tool because of a simple mistake in paths or so.
With regards to U-Boot proper, I would say the same is true of "mkimage" which conflicts with jigdo. In essence, while U-Boot is usually installed into a user's home directory (~/bin etc.) simple path mixups, going to root shell, using another box etc. means you may have multiple same-named tools on a system for various work, which do different things.
Is it possible that we could standardize on some tool naming here?
I'm going to rename in the package these tools to "mkuimage" (since this goes well with suse mkzimage) and "fdtdump" for my package anyway so no worries if nothing ever gets done.. but since the Fedora guys were packaging dtc up right now I thought I would mention this as the RPM I downloaded from FC10 the other day did not take note of this (and RPM warns that there is a conflict but happily overwrites the file anyway, thus trashing Freetype :)
(why am I packaging U-Boot tools like mkimage? We need them for post-install script on a kernel RPM..)
--
Matt Sealey
Genesi, Manager, Developer Relations
Quoted 18 lines · Matt Sealey
I just noticed (was told by an affiliate) that the DTC compiler tools shares a tool name "ftdump" with the Freetype project. I was doing a lazy packaging effort to get a few tools around so we can all be running the same version and build some custom kernel RPMs, and this came up.
Wouldn't a better name be "fdtdump", do you think? It's usually not a fun idea to conflict with tools already on the system. A user may run "ftdump" and get the Freetype tool because of a simple mistake in paths or so.
With regards to U-Boot proper, I would say the same is true of "mkimage" which conflicts with jigdo. In essence, while U-Boot is usually installed into a user's home directory (~/bin etc.) simple path mixups, going to root shell, using another box etc. means you may have multiple same-named tools on a system for various work, which do different things.
Is it possible that we could standardize on some tool naming here?
Quoted 7 lines
I'm going to rename in the package these tools to "mkuimage" (since this goes well with suse mkzimage) and "fdtdump" for my package anyway so no worries if nothing ever gets done.. but since the Fedora guys were packaging dtc up right now I thought I would mention this as the RPM I downloaded from FC10 the other day did not take note of this (and RPM warns that there is a conflict but happily overwrites the file anyway, thus trashing Freetype :)
The Fedora package doesn't install ftdump. Where did you get the package from?
F9 machine:
[jwboyer@yoda ~]$ sudo repoquery -ql dtc/usr/bin/dtc/usr/share/doc/dtc-1.1.0/usr/share/doc/dtc-1.1.0/GPL
[jwboyer@yoda ~]$
F10 machine:
[jwboyer@zod ~]$ sudo repoquery -ql dtc/usr/bin/dtc/usr/share/doc/dtc-1.2.0/usr/share/doc/dtc-1.2.0/GPL
[jwboyer@zod ~]$
Quoted 2 lines
(why am I packaging U-Boot tools like mkimage? We need them for post-install script on a kernel RPM..)
I tried to get it included in the kernel tarball. It didn't get very far because Sam was too busy to really reply.
josh
Quoted 27 lines · Josh Boyer
Quoted 18 lines · Matt Sealey
I just noticed (was told by an affiliate) that the DTC compiler tools shares a tool name "ftdump" with the Freetype project. I was doing a lazy packaging effort to get a few tools around so we can all be running the same version and build some custom kernel RPMs, and this came up.
Wouldn't a better name be "fdtdump", do you think? It's usually not a fun idea to conflict with tools already on the system. A user may run "ftdump" and get the Freetype tool because of a simple mistake in paths or so.
With regards to U-Boot proper, I would say the same is true of "mkimage" which conflicts with jigdo. In essence, while U-Boot is usually installed into a user's home directory (~/bin etc.) simple path mixups, going to root shell, using another box etc. means you may have multiple same-named tools on a system for various work, which do different things.
Is it possible that we could standardize on some tool naming here?
Quoted 7 lines
I'm going to rename in the package these tools to "mkuimage" (since this goes well with suse mkzimage) and "fdtdump" for my package anyway so no worries if nothing ever gets done.. but since the Fedora guys were packaging dtc up right now I thought I would mention this as the RPM I downloaded from FC10 the other day did not take note of this (and RPM warns that there is a conflict but happily overwrites the file anyway, thus trashing Freetype :)
Quoted 2 lines
The Fedora package doesn't install ftdump. Where did you get the package from?
Fedora website. I *did* modify it a tad because I actually use ftdump to verify the content of the device trees I'm booting :)
However if anyone ever did want it, and you put it in your RPM, you'd need to change the name. Sorry I wasn't so clear, but I think it would be "good behaviour" if U-Boot or DTC or any other app (I can probably come up with some decent examples) did not use rather generic tool names which walk all over other tool names potentially on a system :)
Quoted 5 lines
Quoted 2 lines
(why am I packaging U-Boot tools like mkimage? We need them for post-install script on a kernel RPM..)
I tried to get it included in the kernel tarball. It didn't get very far because Sam was too busy to really reply.
That would be nice but it would never help me. I have to run the SUSE kernel of the last release, which right now is 2.6.27.7 - any efforts to get it in that have happened in the previous 6 months would have been missed by the time SUSE standardized :(
-- Matt
Hi Matt,
Quoted 12 lines · Matt Sealey
Quoted 11 lines · Josh Boyer
Quoted 10 lines · Matt Sealey
I just noticed (was told by an affiliate) that the DTC compiler tools shares a tool name "ftdump" with the Freetype project. I was doing a lazy packaging effort to get a few tools around so we can all be running the same version and build some custom kernel RPMs, and this came up.
Wouldn't a better name be "fdtdump", do you think? It's usually not a fun idea to conflict with tools already on the system. A user may run "ftdump" and get the Freetype tool because of a simple mistake in paths or so.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
With regards to U-Boot proper, I would say the same is true of "mkimage" which conflicts with jigdo. In essence, while U-Boot is usually installed into a user's home directory (~/bin etc.) simple path mixups, going to root shell, using another box etc. means you may have multiple same-named tools on a system for various work, which do different things.
Mkimage and ftdump are different audiences (OK, the same people but the chairs are arranged differently ;-).
[snip]
IMHO, the ftdump issue needs to be addressed at the DTC level (Jon Loeliger and David Gibson). U-Boot (and the linux kernel) is being driven by DTC.
I won't address mkimage since I don't have a dog in that fight.
[snip]
Quoted 1 line
-- Matt
Best regards,
gvb
Quoted 23 lines · Jerry Van Baren
Hi Matt,
Quoted 13 lines · Matt Sealey
Quoted 12 lines · Josh Boyer
Quoted 11 lines · Matt Sealey
I just noticed (was told by an affiliate) that the DTC compiler tools shares a tool name "ftdump" with the Freetype project. I was doing a lazy packaging effort to get a few tools around so we can all be running the same version and build some custom kernel RPMs, and this came up.
Wouldn't a better name be "fdtdump", do you think? It's usually not a fun idea to conflict with tools already on the system. A user may run "ftdump" and get the Freetype tool because of a simple mistake in paths or so.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
With regards to U-Boot proper, I would say the same is true of "mkimage" which conflicts with jigdo. In essence, while U-Boot is usually installed into a user's home directory (~/bin etc.) simple path mixups, going to root shell, using another box etc. means you may have multiple same-named tools on a system for various work, which do different things.
Quoted 8 lines
Mkimage and ftdump are different audiences (OK, the same people but the chairs are arranged differently ;-).
[snip]
IMHO, the ftdump issue needs to be addressed at the DTC level (Jon Loeliger and David Gibson). U-Boot (and the linux kernel) is being driven by DTC.
David has said before that ftdump is sort of a pointless debugging tool. Or at least that is what the Debian bug report referrenced as the reason from removing it from the Debian dtc package.
Maybe we should just remove it entirely if it's not really going to be maintained long-term.
josh
A message that is not in the archive (sent off-list or not yet received): 20090114191905.GA18581-JVa43G0qJ78RlTYtMZUE4cJ8OCA1ciLf@public.gmane.org
Quoted 29 lines · Josh Boyer
Quoted 28 lines · Jerry Van Baren
Hi Matt,
Quoted 13 lines · Matt Sealey
Quoted 12 lines · Josh Boyer
Quoted 11 lines · Matt Sealey
I just noticed (was told by an affiliate) that the DTC compiler tools shares a tool name "ftdump" with the Freetype project. I was doing a lazy packaging effort to get a few tools around so we can all be running the same version and build some custom kernel RPMs, and this came up.
Wouldn't a better name be "fdtdump", do you think? It's usually not a fun idea to conflict with tools already on the system. A user may run "ftdump" and get the Freetype tool because of a simple mistake in paths or so.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
With regards to U-Boot proper, I would say the same is true of "mkimage" which conflicts with jigdo. In essence, while U-Boot is usually installed into a user's home directory (~/bin etc.) simple path mixups, going to root shell, using another box etc. means you may have multiple same-named tools on a system for various work, which do different things.
Mkimage and ftdump are different audiences (OK, the same people but the chairs are arranged differently ;-).
[snip]
Quoted 7 lines
Quoted 3 lines
IMHO, the ftdump issue needs to be addressed at the DTC level (Jon Loeliger and David Gibson). U-Boot (and the linux kernel) is being driven by DTC.
David has said before that ftdump is sort of a pointless debugging tool. Or at least that is what the Debian bug report referrenced as the reason from removing it from the Debian dtc package.
Yeah, I wouldn't suggest packaging ftdump. It's potentially useful for debugging dtc itself, but if you want to dump a device tree "for real", you can use "dtc -I dtb -O dts".
Quoted 2 lines
Maybe we should just remove it entirely if it's not really going to be maintained long-term.
Hmm, perhaps. We should definitely remove it from the make install target.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Quoted 3 lines · Josh Boyer
David has said before that ftdump is sort of a pointless debugging tool. Or at least that is what the Debian bug report referrenced as the reason from removing it from the Debian dtc package.
As long as you have the original device tree source code to hand. I tend to find that the guy who sent me the device tree and kernel for me to test, has gone to bed and will not be back for 8 to 10 hours. Rather than hang around, on the event that I think it's a device tree problem I tend to ftdump to see what's going on.
It might have some use somewhere someday, but yeah.. I guess.. bringing it out from a build into a package is kind of a dumb idea.
Quoted 2 lines
Maybe we should just remove it entirely if it's not really going to be maintained long-term.
Up to you.
-- Matt
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 11 lines · Matt Sealey
Quoted 3 lines · Josh Boyer
David has said before that ftdump is sort of a pointless debugging tool. Or at least that is what the Debian bug report referrenced as the reason from removing it from the Debian dtc package.
As long as you have the original device tree source code to hand. I tend to find that the guy who sent me the device tree and kernel for me to test, has gone to bed and will not be back for 8 to 10 hours. Rather than hang around, on the event that I think it's a device tree problem I tend to ftdump to see what's going on.
Like I said, "dtc -I dtb -O dts" is the non-hacky way to do this.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson