linux-kernel - Re: [RFC] m68k: Update defconfigs

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 5 Jan 2012 22:42:54 +1100 (EST)
From:	Finn Thain <fthain@...egraphics.com.au>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
cc:	Linux/m68k <linux-m68k@...ts.linux-m68k.org>,
	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	Debian GNU/Linux m68k <debian-68k@...ts.debian.org>
Subject: Re: [RFC] m68k: Update defconfigs

On Wed, 4 Jan 2012, Geert Uytterhoeven wrote:

> Findings:
>   - CONFIG_BLK_DEV_SWIM is m, while CONFIG_AMIGA_FLOPPY and
>     CONFIG_ATARI_FLOPPY are y.

My defconfig patch used "m" because (if I recall correctly) the SWIM 
driver is experimental code that couldn't be safely loaded on all 
machines.

>   - Amiga and Atari use CONFIG_RTC_CLASS, the others don't.
>     Should we switch everything to CONFIG_RTC_CLASS (and thus drop
>     CONFIG_GEN_RTC)? We do have CONFIG_RTC_DRV_GENERIC now.

This would alter the device major/minor numbers and devtmpfs path, right?

Also I wonder about CONFIG_RTC_HCTOSYS on Macs without a working RTC 
driver. Would enabling CONFIG_RTC_HCTOSYS change present behaviour?

I suppose it might need some testing. Otherwise, I think harmonising this 
across defconfigs (and distro configs) is a good idea.

Finn
--
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/