From: Marcin Dalecki <dalecki@evision.ag>
To: Alexander Viro <viro@math.psu.edu>
Cc: martin@dalecki.de, Richard Gooch <rgooch@ras.ucalgary.ca>,
Linus Torvalds <torvalds@transmeta.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.5.27 devfs
Date: Mon, 22 Jul 2002 20:46:31 +0200 [thread overview]
Message-ID: <3D3C5307.2090404@evision.ag> (raw)
In-Reply-To: Pine.GSO.4.21.0207221412240.7619-100000@weyl.math.psu.edu
Alexander Viro wrote:
>
> On Mon, 22 Jul 2002, Marcin Dalecki wrote:
>
>
>>Richard Gooch wrote:
>>
>>>Marcin Dalecki writes:
>>>
>>>
>>>>Kill two inlines which are notwhere used and which don't make sense
>>>>in the case someone is not compiling devfs at all.
>>>
>>>
>>>Rejected. Linus, please don't apply this bogus patch. External patches
>>>and drivers rely on the inline stubs so that #ifdef CONFIG_DEVFS_FS
>>>isn't needed.
>>
>>Dare to actually *name* one of them?
>
>
> [snip]
>
> OK, that's enough. Martin, kindly stay the fsck away from that pile of
> garbage for a couple of weeks.
>
> _All_ partition-related code is getting rewritten and the last thing
> we need right now is additional clutter in the neighborhood. And
> devfs_fs_kernel.h, shite as it is, qualifies.
No problem as long as long somebody cares.
That part stuff needs treatment as well is obvious if one looks at the
extensive allocation fallback chains I have in my small sand pille...
Would you dare to keep the following botch in mind as well please:
/*
* Returns the (struct ata_device *) for a given device number. Return
* NULL if the given device number does not match any present drives.
*/
struct ata_device *get_info_ptr(kdev_t i_rdev)
{
unsigned int major = major(i_rdev);
int h;
for (h = 0; h < MAX_HWIFS; ++h) {
struct ata_channel *ch = &ide_hwifs[h];
if (ch->present && major == ch->major) {
int unit = DEVICE_NR(i_rdev);
if (unit < MAX_DRIVES) {
struct ata_device *drive = &ch->drives[unit];
if (drive->present)
return drive;
}
break;
}
}
return NULL;
}
This get's feed to the revalidate method.
struct block_device_operations ide_fops[] = {{
.owner = THIS_MODULE,
.open = ide_open,
.release = ide_release,
.ioctl = ata_ioctl,
.check_media_change = ide_check_media_change,
.revalidate = ata_revalidate
}};
and the following ide_xlate_1024(kdev_t i_rdev botch.
I would love to go the bdev way there too :-).
But then please keep in mind that the georgeous random number
device is using the major number of a device all over the kernel...
and it's feeding the following ugly global array:
void add_blkdev_randomness(int major)
{
if (major >= MAX_BLKDEV)
return;
if (blkdev_timer_state[major] == 0) {
rand_initialize_blkdev(major, GFP_ATOMIC);
if (blkdev_timer_state[major] == 0)
return;
}
add_timer_randomness(blkdev_timer_state[major], 0x200+major);
}
Which should of course look more like:
void add_blkdev_randomness(struct block_device *ptr)
{
add_timer_randomness(((unsigned long) ptr) %
SOME_REASONABLE_VALUE, 0x200);
}
Simple couldn't resist:
1. Enabled devfs... system printed far too long
incomprehensive device names and didn't reboot.
2. I disabled automatic devfs mount... system didn't find root part either.
The only single expirence in my life, where I thought that naming disks
C: D: E: Z: isn't the worst thing that can happen.
I went curious and looked there... and *cry*.
next prev parent reply other threads:[~2002-07-22 18:48 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-20 19:22 Linux-2.5.27 Linus Torvalds
2002-07-22 10:42 ` [PATCH] 2.5.27 sysctl Marcin Dalecki
2002-07-22 10:53 ` Christoph Hellwig
2002-07-22 10:56 ` Marcin Dalecki
2002-07-22 11:02 ` Christoph Hellwig
2002-07-22 11:03 ` Marcin Dalecki
2002-07-22 12:51 ` Alexander Viro
2002-07-22 13:02 ` Marcin Dalecki
2002-07-22 11:13 ` Christoph Hellwig
2002-07-22 11:19 ` Dave Jones
2002-07-22 11:19 ` bart
2002-07-22 11:21 ` BALBIR SINGH
2002-07-22 12:30 ` Alan Cox
2002-07-22 11:21 ` Marcin Dalecki
2002-07-22 15:57 ` Daniel Egger
2002-07-22 10:43 ` [PATCH] 2.5.27 devfs Marcin Dalecki
2002-07-22 17:28 ` Richard Gooch
2002-07-22 18:03 ` Marcin Dalecki
2002-07-22 18:19 ` Alexander Viro
2002-07-22 18:46 ` Marcin Dalecki [this message]
2002-07-23 5:04 ` Richard Gooch
2002-07-22 10:45 ` [PATCH] 2.5.27 sched Marcin Dalecki
2002-07-22 10:47 ` [PATCH] 2.5.27 smbiod Marcin Dalecki
2002-07-22 22:29 ` Albert D. Cahalan
2002-07-22 10:50 ` [PATCH] 2.5.27 spinlock Marcin Dalecki
2002-07-24 4:40 ` Rusty Russell
2002-07-22 10:51 ` [PATCH] 2.5.27 wait Marcin Dalecki
2002-07-22 10:53 ` [PATCH] 2.5.27 enum Marcin Dalecki
2002-07-22 20:01 ` Benjamin LaHaise
2002-07-23 2:11 ` David S. Miller
2002-07-23 2:55 ` Alexander Viro
2002-07-24 6:44 ` James H. Cloos Jr.
2002-07-23 12:27 ` Dave Jones
2002-07-23 12:41 ` Marcin Dalecki
2002-07-23 13:05 ` Bartlomiej Zolnierkiewicz
2002-07-24 4:49 ` Rusty Russell
2002-07-24 9:47 ` Dave Jones
2002-07-22 14:08 ` [PATCH] 2.5.27 read_write Marcin Dalecki
2002-07-22 16:55 ` Alan Cox
2002-07-22 16:15 ` [PATCH] 2.5.27 read_write - take 2 Marcin Dalecki
2002-07-22 17:04 ` [PATCH] 2.5.27 read_write Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D3C5307.2090404@evision.ag \
--to=dalecki@evision.ag \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@dalecki.de \
--cc=rgooch@ras.ucalgary.ca \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox