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. <df7...@gmail.com> 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. <df7...@gmail.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 <rdun...@infradead.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
