linux-kernel - Re: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080102175400.3C2E0EF588@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
Date:	Wed, 02 Jan 2008 09:54:00 -0800
From:	David Brownell <david-b@...bell.net>
To:	mingo@...e.hu, kay.sievers@...y.org
Cc:	a.zummo@...ertech.it, stern@...land.harvard.edu, rjw@...k.pl,
	pavel@...e.cz, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	lenb@...nel.org, gregkh@...e.de, akpm@...ux-foundation.org
Subject: Re: [PATCH 0/4] PM: Do not destroy/create devices while suspended 
 (rev. 2)

> > > shouldnt we provide a Kconfig way of replacing dev 10:135 with the 
> > > new driver's 254:0 device? (while keeping all the current modes of 
> > > operation as well, of course.) It's all supposed to be 100% ioctl 
> > > ABI compatible with the old driver, right?
> > 
> > It's not compatible enough to "fake" only the old major/minor. Userspace
> > must be fixed not to depend on stuff like:  /proc/sys/dev/rtc/max-user-freq:
> >   http://lkml.org/lkml/2007/8/4/183
>
> i think that should be fixed by providing a compatible 
> /proc/sys/dev/rtc/max-user-freq implementation in the new driver too.

I see /sys/class/rtc/rtc0/max_user_freq, fwiw ...


> > > That way distros could start migrating to it
> > > as well, without depending on any udev hackery.
> > 
> > It's in the default udev setup:
> >   KERNEL=="rtc|rtc0",             MODE="0644"
> >   KERNEL=="rtc0",                 SYMLINK+="rtc"
>
> but if it breaks max-user-freq (which is needed by qemu for example) 
> then distros would likely disable it, right?
>
> or this rule might be broken in some way. For example my Fedora 8 box 
> has this in /etc/udev/rules.d/50-udev-default.rules:
>
>  # miscellaneous
>  KERNEL=="fuse",                 MODE="0666"
>  KERNEL=="rtc|rtc0",             MODE="0644"
>  KERNEL=="rtc0",                 SYMLINK+="rtc"
>
> still i've got:
>
>  crw------- 1 root root  10, 135 Dec 28 08:13 /dev/rtc
>  crw-r--r-- 1 root root 254,   0 Dec 28 08:13 /dev/rtc0

I suspect the /dev/rtc node was provided by the distro, so those
udev rules won't trigger.


> _and_ my distro kernel doesnt even have CONFIG_RTC enabled - i run the 
> Fedora 9 devel/rawhide kernel on this box:
>
>  # CONFIG_RTC is not set
>  # CONFIG_GEN_RTC is not set
>  # CONFIG_HPET_RTC_IRQ is not set
>  CONFIG_RTC_LIB=y
>  CONFIG_RTC_CLASS=y
>  # CONFIG_RTC_HCTOSYS is not set
>  # CONFIG_RTC_DEBUG is not set
>  # RTC interfaces
>  CONFIG_RTC_INTF_SYSFS=y
>  CONFIG_RTC_INTF_PROC=y
>  CONFIG_RTC_INTF_DEV=y
>  # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
>  # CONFIG_RTC_DRV_TEST is not set
>
> udev-116-3.fc8.

I run my x86 systems like that (also with RTC_DRV_CMOS), but
the ARM systems usually have RTC_HCTOSYS set too (plus some
RTC driver other than rtc-cmos).  The x86 system init code
pokes directly at the legacy RTC hardware in several cases.


>	Maybe i just misunderstood what the grand plan was here 
> - i assumed it was to smoothly convert from old driver to new driver, 
> without forcing any changes on user-space.

If there was a Grand Plan, I never heard of it. :)

It'd need to have some NTP sync solution for RTC_LIB devices, but
ISTR the gentime stuff still assumes an update_persistent_clock()
that doesn't sleep ... and hence can't be used with I2C based RTCs.


I've been trying to make sure the x86 world could realistically
switch to the RTC framework used by other Linux platforms, hence
e.g. the util-unix-ng updates, but never assumed there would be
no userspace changes.  After all, userspace was using a mishmash
of tools that were far from platform-agnostic, and moving away
from x86-dependency implies such things will change.

However I *do* think that symlinking rtc to /dev/rtc0 should
make it practical to use most older binaries.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/