[OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin

Mark Hatle mark.hatle at windriver.com
Wed Dec 5 14:00:37 UTC 2012


On 12/5/12 7:31 AM, Shakeel, Muhammad wrote:
> Hi Chen Qi,
>
> Seems like baselib is getting value from here:
> baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) or 'INVALID'), True) or 'lib'}"
>
> In your conf file, tune-mips64.inc requires arch-mips.inc which sets:
>
> DEFAULTTUNE ?= "mips"
> and then:
> BASE_LIB_tune-mips = "lib"
>
> This seems to be the reason that why you get /lib in 'baselib' even for mips64 arch.
>
> I have a modified conf file which sets 'DEFAULTTUNE" to 'mips64'  explicitly.

It really should be the machine configuration that sets the DEFAULTTUNE properly 
for the board.  While the tune-mips64.inc should likely set a DEFAULTTUNE ?= 
"mips64" it doesn't have to be done that way... and in this case there is a 
reason it's not.

On most MIPS architectures, people are not going to actually want the default 
tune to be MIPS64, what they really want is an alterantive library support for 
MIPS64, with a primary library of either o32 (mips32) or n32 (32-bit mips64). 
This is why it's really up to the machine configuration, and ultimately the end 
user's configuration to determine the appropriate DEFAULTTUNE... the tune files 
are just guidelines to make it easier.

> DEFAULTTUNE="mips64"
>
> And arch-mips.inc has:
> BASE_LIB_tune-mips64 = "lib64"
>
> I am sure if you modify DEFAULTTUNE in your conf file then you will get /lib64 in baselib.
>
> (Sorry for replying late as I forgot to flag this conversation.)
>
> Regards,
> Shakeel
>
> -----Original Message-----
> From: ChenQi [mailto:Qi.Chen at windriver.com]
> Sent: Friday, November 30, 2012 11:01 AM
> To: Shakeel, Muhammad
> Cc: openembedded-core at lists.openembedded.org; Otavio Salvador
> Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
>
> On 11/28/2012 07:09 PM, Shakeel, Muhammad wrote:
>> If we ensure that udev will always be found in /lib/udev/udevd then this patch will not be required.
>>
>> Actually I needed this patch to start udev on a mips64 target where ${base_libdir} is '/lib64' and original udev init script was failing to start udev.
>> (I am not using initramfs).
>>
>> --Shakeel
> Hi Muhammad,
>
> I'm somewhat confused by this 'baselib' problem. I just built udev on a test machine which has mips64 arch. But it turned out that its baselib was '/lib' instead of '/lib64'.
>
> How did you get '/lib64' on a mips64 target?
>
> My test machine's conf file is:
> "
> require conf/machine/include/tune-mips64.inc
>
> KERNEL_IMAGETYPE = "vmlinux"
> KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
>
> SERIAL_CONSOLE = "115200 ttyS0"
>
> MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> "
>
> Besides, I tried it on x86-64.  As long as we don't explicitly specify multilib (lib64) for udev, it defaults to '/lib'.
>
> I seems that the baselib defaults to '/lib64' only when the target has
> powerpc64 arch.
>
> Could you please give me some more information to help me?
>
> Thanks,
> Chen Qi
>
>> -----Original Message-----
>> From: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On
>> Behalf Of Otavio Salvador
>> Sent: Wednesday, November 28, 2012 3:52 PM
>> To: ChenQi
>> Cc: Shakeel, Muhammad; openembedded-core at lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] udev 182: Create a symlink of
>> /lib/udev/udevd in /sbin
>>
>> On Wed, Nov 28, 2012 at 12:26 AM, ChenQi<Qi.Chen at windriver.com>  wrote:
>>> On 11/27/2012 10:15 PM, Otavio Salvador wrote:
>>>> On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad
>>>> <muhammad_shakeel at mentor.com>   wrote:
>>>>> From: Muhammad Shakeel<muhammad_shakeel at mentor.com>
>>>>>
>>>>>     From udev 174 changelog:
>>>>> "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
>>>>> and non-dracut initramfs image generators need to change the init
>>>>> scripts. Alternatively the udev build needs to move udevd back to
>>>>> /sbin or create a symlink in /sbin, which is not done by default."
>>>>>
>>>>> Also for 64 bit architectures there exists /lib64/udev instead of
>>>>> /lib/udev and current init script fails to start udev.
>>>>>
>>>>> Signed-off-by: Muhammad Shakeel<muhammad_shakeel at mentor.com>
>>>> As far as I know, all code in master now handles it properly (the
>>>> missing bits I sent a patch today) so why to include this symlink?
>>>>
>>> I'm not sure about this.
>>>
>>> Two things:
>>>
>>> 1) Have we ever tested udev on a target where its ${base_libdir} is
>>> '/lib64'?
>>> Apparently, if udevd is intalled under '/lib64', its init script
>>> cannot start udev correctly.
>>>
>>> 2) Bug#2804 is related to to udev and ${base_libdir}.
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804
>>> (Some packages hardcode their udev rules directory to be
>>> '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is
>>> '/lib64'? )
>> It seems the right fix for it is to ensure udev is always installed in /lib/udev/udevd (for all targets) as you propose to do for the rules.d directory.
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>





More information about the Openembedded-core mailing list