| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously, the number registry did a pruning pass whenever elements,
either all or a filtered subset, were queried by a consumer. This meant,
that every access to elements did an additional O(n) scan of the entire
registry, to ensure no expired devices were still registered. This used
to be necessary, when the ownership model for devices was still in flux.
With the established device ownership model, this has become obsolete.
Additionally, devices get numbered automatically when a device gains a
facet the is observed by the device number registry. Since registering
this type of facet is the responsibility of the device driver, since
only a driver can know how to implement that facet for any given device,
it also becomes the responsibility of the driver to revoke that facet
if and when a device is detached from the system. Any device is always
owned by the bus it is attached to. This means it is the bus'
responsibility to inform drivers about devices disappearing. This closes
the chain of responsibility cleanly, meaning the device number registry
will never have to prune itself in any accessors. Instead, it will be
informed by the facet registry that a facet for a device has been
revoked, allowing it to un-number that device if applicable.
|
|
|
|
The coding guidelines explicitly prohibit the use of "naked"/C-style
pointers. However, there were some prominent examples in the kapi and
the core kernel source. This changeset replaces them with the
appropriate smart pointer types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
POSIX requires that the data returned by the readdir() function shows
the inode number of the root of a mounted filesystem for its mount
point. Additionally, the inode number of the '..' reference in the
mounted filesystem must show the inode number of the mount point.
We perform this fixup when computing the entries during read_directory
on the fly. The implementation of the upward fixup will need to be
revised once the kernel supports bind mounts.
|
|
|
|
|
|
|
|
Previously, the device filesystem (devfs) was simply grafted on each
root filesystem during boot. This caused the existence of an
unreachable, dead devfs mount after the VFS instance had been
initialized.
This changeset implements the ability to relocate an active mount from
one mount point to another. That way, no second devfs mount needs to be
created. Instead, the existing devfs mount is relocated to a mount point
in the persistent root filesystem that get mounted during
initialization.
Secondly, this changeset also alters the VFS initialization flow, so
that only one root mount exists after initialization finishes.
|
|
|
|
When computing the actual block numbers for a filesystem, care must be
taken to account for which block is the actual first data block. For
1 KiB block size filesystems, that block is actually block 1, not 0.
This is because the first 1 KiB on any ext2 volume is reserved for
bootloader data.
Complicating matters, the bitmaps don't take this into account. They
essentially reflect a logical view, describing which data blocks are
already allocated. On a 1 KiB filesystem, this effectively means that
bit 0 of the allocation bitmap references physical block 1.
Luckily, we don't need to make that determination based on the block
size at all. The superblock already carries the number of the first data
block. That means one can simply add that number, which is 1 in the
1 KiB block size case and 0 otherwise, to the found block index.
Interestingly, this was already caught by accident when locating the
authoritative block group descriptor (BGD) table. A factor of two was
multiplied into the calculation in the case of a 1 KiB block size. This
factor arises because the primary BGD table follows the primary
superblock. Since the superblock is located in physical block 0 in all
cases except for a 1 KiB block size, the BGD table generally lands in
block 1. This implies an offset of 1 block size from the volume start.
In the 1 KiB case, the BGD table lands in block number 2, effectively at
an offset of 2 blocks from the start of the volume.
This changeset makes that calculation explicit in the BGD table locator
code as well. This clarifies the previously obscure factor of 2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change also replaces the kernel internal directory_listing_cursor
and directory_listing_entry with the kapi types directory_cursor and
directory_entry.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The previous sentinel value would have prevent a device with major:minor
255:255 from showing up, if the read buffer was small enough to just
barely not read that device in one go. The new value is an actually
invalid device number, so it does not preclude any devices from showing
up in directory listings.
|
|
|
