linuxsh-dev

RTC device Major/Minor Number

[EXTERNAL B. M. (P. ST-FIR/Eng) <ext...@de...>]

Hi,

why isn't /dev/rtc the well known "c 10 135" device that it's on x86,
but a magic undocumented "c 254 0" device?=20
Devices.txt lists this major number as LOCAL/EXPERIMENTAL USE.=20

Regards

Markus

Re: RTC device Major/Minor Number

[Mike F. <va...@ge...>]

On Wednesday 29 August 2007, EXTERNAL Brunner Markus (Praktikant; ST-FIR/En=
g)=20
wrote:
> why isn't /dev/rtc the well known "c 10 135" device that it's on x86,

just because x86 has crap doesnt mean everyone else needs to suffer

> but a magic undocumented "c 254 0" device?
> Devices.txt lists this major number as LOCAL/EXPERIMENTAL USE.

it's magic because it's dynamic

properly architected systems should not know/care what the major/minor numb=
ers=20
are
=2Dmike

Re: RTC device Major/Minor Number

[Mike F. <va...@ge...>]

On Wednesday 29 August 2007, EXTERNAL Brunner Markus (Praktikant; ST-FIR/En=
g)=20
wrote:
> why isn't /dev/rtc the well known "c 10 135" device that it's on x86,
> but a magic undocumented "c 254 0" device?
> Devices.txt lists this major number as LOCAL/EXPERIMENTAL USE.

a follow up i should have included originally ... what rtc driver are you=20
using ?
=2Dmike

Re: RTC device Major/Minor Number

[Paul M. <le...@li...>]

On Wed, Aug 29, 2007 at 04:36:37PM +0200, EXTERNAL Brunner Markus (Praktikant;  ST-FIR/Eng) wrote:
> why isn't /dev/rtc the well known "c 10 135" device that it's on x86,
> but a magic undocumented "c 254 0" device? 
> Devices.txt lists this major number as LOCAL/EXPERIMENTAL USE. 
> 
This is a bit of an intentional namespace conflict. The 10 135 device is
a legacy driver, and even x86 is moving away from that in favour of
dynamic numbers. The new drivers/rtc/ subsystem is entirely dynamic, so
all of the architectures using this behave the same way. Static device
nodes are a relic of the past, and new system designs should not depend
on them.

Even without udev, you can still get a link to the device node via sysfs,
so it's possible to script around this, but you really should be using
udev. hwclock and friends generally work transparently regardless of
whether the legacy driver is in use or not.