Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAGRSmLsV96jK+7UB6T6k8j9u74oPSHTA+1TPU8F9G2NnOqCDJg@mail.gmail.com>
 <c0d9d434-1f47-66a0-1129-5003f2f2eb5c@infradead.org>
In-Reply-To: <c0d9d434-1f47-66a0-1129-5003f2f2eb5c@infradead.org>
From:   "David F." <df7729@gmail.com>
Date:   Mon, 30 Sep 2019 17:13:23 -0700
Message-ID: <CAGRSmLv-9dtPWmANMD64E7Lv++L4_y5anJ2SPWsw9J1kiDuegw@mail.gmail.com>
Subject: Re: What populates /proc/partitions ?
To:     Randy Dunlap <rdunlap@infradead.org>, masneyb@onstation.org
Cc:     linux-kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@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