mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David F." <df7729@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>, masneyb@onstation.org
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: What populates /proc/partitions ?
Date: Mon, 30 Sep 2019 20:38:50 -0700	[thread overview]
Message-ID: <CAGRSmLuChjV8nXuOvu54kY9ejSZT1akGo_axAzD2mn++zHJXWw@mail.gmail.com> (raw)
In-Reply-To: <CAGRSmLv-9dtPWmANMD64E7Lv++L4_y5anJ2SPWsw9J1kiDuegw@mail.gmail.com>

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

  reply	other threads:[~2019-10-01  3:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 22:47 David F.
2019-09-30 23:46 ` Brian Masney
2019-09-30 23:49 ` Randy Dunlap
2019-10-01  0:13   ` David F.
2019-10-01  3:38     ` David F. [this message]
2019-10-01  4:59       ` David F.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGRSmLuChjV8nXuOvu54kY9ejSZT1akGo_axAzD2mn++zHJXWw@mail.gmail.com \
    --to=df7729@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masneyb@onstation.org \
    --cc=rdunlap@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®