[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGRSmLuChjV8nXuOvu54kY9ejSZT1akGo_axAzD2mn++zHJXWw@mail.gmail.com>
Date: Mon, 30 Sep 2019 20:38:50 -0700
From: "David F." <df7729@...il.com>
To: Randy Dunlap <rdunlap@...radead.org>, masneyb@...tation.org
Cc: linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: What populates /proc/partitions ?
Well, it's not straightforward. No direct calls, it must be somehow
when kmod is used to load the module. The only difference I see in
the udevadm output is the old system has attribute differences
capability new==11, old==1, event_poll_msec new=2000, old=-1. I
figured if i could set the "hidden" attribute to 1 then it looks like
/proc/partitions won't list it (already "removable"attribute), but
udev doesn't seem to allow changing the attributes, only referencing
them. unless I'm missing something?
On Mon, Sep 30, 2019 at 5:13 PM David F. <df7729@...il.com> wrote:
>
> Thanks for the replies. I'll see if I can figure this out. I know
> with the same kernel and older udev version in use that it didn't add
> it, but with the new udev (eudev) it does (one big difference is the
> new one requires and uses devtmpfs and the old one didn't).
>
> I tried making the floppy a module but it still loads on vmware player
> and the physical test system I'm using that doesn't have one but
> reports it as existing (vmware doesn't hang, just adds fd0 read errors
> to log, but physical system does hang while fdisk -l, mdadm --scan
> runs, etc..).
>
> As far as the log, debugging udev output, it's close to the same, the
> message log (busybox) not much in there to say what's up. I even
> tried the old .rules that were being used with the old udev version,
> but made no difference.
>
> On Mon, Sep 30, 2019 at 4:49 PM Randy Dunlap <rdunlap@...radead.org> wrote:
> >
> > On 9/30/19 3:47 PM, David F. wrote:
> > > Hi,
> > >
> > > I want to find out why fd0 is being added to /proc/partitions and stop
> > > that for my build. I've searched "/proc/partitions" and "partitions",
> > > not finding anything that matters.
> >
> > /proc/partitions is produced on demand by causing a read of it.
> > That is done by these functions (pointers) in block/genhd.c:
> >
> > static const struct seq_operations partitions_op = {
> > .start = show_partition_start,
> > .next = disk_seqf_next,
> > .stop = disk_seqf_stop,
> > .show = show_partition
> > };
> >
> > in particular, show_partition(). In turn, that function uses data that was
> > produced upon block device discovery, also in block/genhd.c.
> > See functions disk_get_part(), disk_part_iter_init(), disk_part_iter_next(),
> > disk_part_iter_exit(), __device_add_disk(), and get_gendisk().
> >
> > > If udev is doing it, what function is it call so I can search on that?
> >
> > I don't know about that. I guess in the kernel it is about "uevents".
> > E.g., in block/genhd.c, there are some calls to kobject_uevent() or variants
> > of it.
> >
> > > TIA!!
> >
> > There should be something in your boot log about "fd" or "fd0" or floppy.
> > eh?
> >
> > --
> > ~Randy
Powered by blists - more mailing lists