Message-ID: <CAGRSmLtk9UieN=pFMjaALPupeJM8axaD4B1_bhHmN2uGR9242w@mail.gmail.com>
Date:   Mon, 30 Sep 2019 21:59:56 -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 ?

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. <df7729@...il.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. <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