netbsd-gsoc-setroot

@netbsd-gsoc-setroot

NetBSD Google Summer of Code - root file system selection unit tests

Public team

Joined on May 11, 2024

  • regular meetings We will meet up daily for short "stand-up" style meeting to discuss progress, blocking issues and next steps. We meet on ICB/IRC and switch to Jitsi if necessary. time difference India Standard Time is 3.5 hours ahead of Middle European Summer Time. video conferencing / screen sharing netbsd-gsoc on Freifunk Muenchen Jitsi
     Like  Bookmark
  • Diviyam Chris November 13.-21. away but working during the day November 17.-19. away DENOG16 conference September 25. away September 18.-23. away July 19.-26. away July 12.-14. away
     Like  Bookmark
  • OK, here we go... First of all, I do not expect you to solve all the problems you run into on you own. It is good if you do try. But don't spend too much time on it. Give it a try and then ask me for help, please. I will try had to not make too many assumptions. And I expect that you try to read documenation and man pages. But I will give you hints on what to read and what to look for.
     Like  Bookmark
  • conventions used in this document sourcefile:functionname() sourcefile paths will be relative to src/sys/, e.g. kern/kern_subr.c:setroot() we use links to NXR to point to source code. E.g. [setroot()](https://nxr.netbsd.org/xref/src/sys/kern/kern_subr.c#193) NB: these links reference absolute line numbers. the actual line number might be slightly off, if the corresponding source file has been changed since creating the link. device configuration during boot the kernel needs to configure a lot of hardware devices in the system to bring them into a known state and to probe for the presence of optional hardware like disks, network cards etc. to facilitate this a description of all the devices that the kernel needs to know about is created and processed by config(8)which is then compiled into the kernel image.
     Like  Bookmark
  • Testing Setroot slide: what we're doing: testing parts of the bootstrap process Overview of Rumpkernel A Rump Kernel is a lightweight, modular kernel that is designed to allow reutilization of kernel components in different environments, such as userspace and a full operating system, without the need for a full operating system. Rump Kernel is a kernel comprising lone kernel components like drivers, file systems, or network stacks, all usable in isolation or together. This modularity enables the inclusion of only components that developers require, reducing overhead in the process.
     Like  Bookmark
  • In x86/x86_autoconf.c. findroot() attempts to find the device (a device_t) from which the kernel was loaded and changes rootdev (another device_t), if allowed to do so. It does this in 6 steps: If booted_device (a device_t) is already set, it just returns, not setting rootdev. The assumption seems to be, that the kernel was booted from the network and device_register() already has set booted_device. If BTINFO_NETIF is available (but booted_device isn't set), it just returns, logging a message that the netboot interface wasn't found. BTINFO_ROOTDEVICE is non-NULL. biv->devname is expected to be of the form "drivername<unitdigit><partitionletter>". It loops over all disk devices looking for a device who's cfname is the same as drivername. Iff such a device is found it sets the following variables:
     Like  Bookmark
  • Both [ ] prepare a plan for the next 2 weeks Chris [x] prepare a short walkthrough of setroot() and related functions. [ ] write documentation for findroot() based on existing documentation. [ ] write documentation for device_register() (x86, amd64, i386, xen). [ ] prepare a list of global variables used by setroot() [x] put the scripts directory under version control. [ ] prepare a short walkthrough about using ddb(4)
     Like  Bookmark
  • Here we keep a record what we discussed. We also document project progress. The list is most recent entry first. 2024-07-08 some additions to aprint gsoc-setroot commit review and more tasks TODO in task list unscheduled [ ] copy editing Documentation for setroot().
     Like  Bookmark
  • ​​​​these structs maybe represent 4 methods of booting/possible root device candidates All the struct below are assigned value by this functionlookup_bootinfo(int type) with particular integer value assigned to device category. they are then Checked with Null object struct btinfo_rootdevice *biv;XXXDon't know what device it is maybe bios has recognised root device,can bios even do that it has following conditions to assign booted* variables value. Also bootspec is ONLY set in this case after condition that devname field is equal to '/0'.devclass of iterating device should be DV_DISK contents cf_name field of iterating device should be same as contents of devname field of biv for length of cf_name && length of devname field of biv after removing 'a' should be same as unit of device iterating. findroot returns if dv is not Null. or if devname field is equal to '/0'. struct btinfo_bootdisk *bid;
     Like  Bookmark
  • Documentation biv->devname[len] - '0' == device_unit(dv) can you elaborate it a litlle bit. @baduck: the - '0' "trick" converts from a character code for a digit to the value of a digit. In C char is actually an integer type, in fact the smallest interger a cpu can represent. So you can do artimethic on it. Character constants are effectively integer contants. In ASCII the digits are consecutive '0', '1', '2', ... '9' with character code '48' for '0' through '58' for '9'. So you could write the above expression as biv->devname[len] - 48 == device_unit(dev) but then people would wonder what the magic number 48 stands for. So the idiom of using the character constant 0 was adopted. That code fragment is a bit fishy, however. It assumes that the devname field only ever has a single trailing digit. I.e. that we never boot from, say, sd10 or higher. This is related to the device naming protocol defined in the Torek paper. Device names are of the form <driver-name><unit-number>. Device driver names consist of letters only. E.g. sd0 is the first unit attached to the sd driver, sd10 is the 11th unit attached to the sd driver. Three lines below it does the same conversion from partition letter a-z to partition number by substracting the character constant 'a'. Note: this code fragment make the assumption that biv->devname has the format <driver-name><unit-digit><partition-letter>. This is something that we should document and base test cases on. XXXdoc, XXXtestcase This is an excellent catch! I would likely have missed this detail if you hadn't asked! is this correct wording link Last case to run checks for CD-ROM boot disk. it assumes biosdev will be larger or equal to maximum number of supported disk drive ie cd device will always be assigned number at last. for​​​​​​​ ` * No booted device found; check CD-ROM boot at last.
     Like  Bookmark
  • Congratulations! :tada: You have created a team workspace, where all team members collaborate on their shared notes. Team roles and note permission All members in the workspace have read access to every note in it. Only writers and admins have write access, and only admins can delete a team note. Team members receive notifications when someone else edit or mention them in a team note. Team members are all considered Owners to notes in the workspace when configuring note permissions.
     Like  Bookmark