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. 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. 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 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
Re: What populates /proc/partitions ?
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. 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 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
Re: What populates /proc/partitions ?
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 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
Re: What populates /proc/partitions ?
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
Re: What populates /proc/partitions ?
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, _op); proc_create_seq("partitions", 0, NULL, _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!!
What populates /proc/partitions ?
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!!