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.
If udev is doing it, what function is it call so I can search on that?
TIA!!
On Mon, Sep 30, 2019 at 03:47:21PM -0700, 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.
It looks like it is done in block/genhd.c with this function:
static int __init proc_genhd_init(void)
{
proc_create_seq("diskstats", 0, NULL, &diskstats_op);
proc_create_seq("partitions", 0, NULL, &partitions_op);
return 0;
}
module_init(proc_genhd_init);
Brian
>
> If udev is doing it, what function is it call so I can search on that?
>
> TIA!!
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
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 <[email protected]> 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
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. <[email protected]> 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 <[email protected]> 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
It has something to do with devtmpfs that causes it. If I could set
this GENHD_FL_HIDDEN flag on it, it would solve the problem on those
system that say the have a floppy but doesn't really exist. Is
something built-in to allow that or it's up to the driver itself?
On Mon, Sep 30, 2019 at 8:38 PM David F. <[email protected]> wrote:
>
> 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. <[email protected]> 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 <[email protected]> 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