[OE-core] [PATCH] makedevs: don't restrict device node paths to 40 characters

[Khem Raj]

> On Sep 12, 2016, at 1:14 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> 
> 40 character paths work OK for device nodes in /dev but not for
> device nodes created in a chroot, LXC container, etc.
> 
> Since the 'path' array is already a 4k buffer, the sscanf 40
> character limit seems to be a typo or historical mis-merge. Update
> the sscanf limit and bring the code in sync with the Buildroot
> version:
> 
>  https://git.buildroot.net/buildroot/commit/?id=8876b6751e0bc19a3754290061808f0f8420708e

what is upstream worthiness of this patch ? it seems it could be
a good change

> 
> Signed-off-by: Andre McCurdy <armccurdy at gmail.com>
> ---
> meta/recipes-devtools/makedevs/makedevs/makedevs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/makedevs/makedevs/makedevs.c b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
> index 7471f3f..cba7681 100644
> --- a/meta/recipes-devtools/makedevs/makedevs/makedevs.c
> +++ b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
> @@ -360,7 +360,7 @@ static int interpret_table_entry(char *line)
> 	unsigned long mode = 0755, uid = 0, gid = 0, major = 0, minor = 0;
> 	unsigned long start = 0, increment = 1, count = 0;
> 
> -	if (0 > sscanf(line, "%40s %c %lo %40s %40s %lu %lu %lu %lu %lu", path,
> +	if (0 > sscanf(line, "%4095s %c %lo %40s %40s %lu %lu %lu %lu %lu", path,
> 		    &type, &mode, usr_buf, grp_buf, &major, &minor, &start,
> 		    &increment, &count))
> 	{
> --
> 1.9.1
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161002/845360da/attachment-0002.sig>