OK from manpages, too. Thanks for addition this feature.

yea, you're right - sbdirty() uses fswritefd. Thanks for pointing it out.

Ok, so you only referenced the devvp vnode in namei().

update to support VLAN MTU...

As far as I can tell, gjournal_check assumes fswritefd is already open, so this is no good.

I've just thought that struct cam_path has own device field. So the function name is confusing.

In D30879#694645, @scottl wrote:

Part of me feels that abstracted definitions for implementation semantics is good API design, but it sounds like this is a good candidate for garbage collection.

This looks good. And I rather like it, since I've wanted something like this in the past.

Thank you. This stuff always broke my brain.

Thanks for the model... I may have to use parts of it in the CAM architecture update in the handbook if you don't mind..

Should be obvious, for aarch64 xen_early_probe() simply ends up being a normal function declaration in sys/arm64/include/xen/xen-os.h and the function in D29875 does the job.

The model is that a sim represents the queueing and resource pool for one or more buses. If multiple buses have their own private resource and scheduling pools, then those buses need to have separate sims. If they share resources, then they need to share the same sim. AHC was weird because even though it had a split "TWIN" mode, apparently the split buses still had independent resource pools and queueing limits. The same was not true with cards that presented logical and physical drives like mpt and ciss; they still draw from the same resource pool, so they needed a single SIM and also need distinctive buses so the physical and logical target numbers don't conflict. This is really a detail of the driver and hardware, and is something that the driver writer should know and understand early in the design phase of development. Even though SAS controllers have multiple "ports", the queueing is still typically common to all ports on the device, so only a single bus is created on the sim.

Yeah, my feeling is still that C function return values should be errno's, and that cam_status should be reserved for use primarily in the status fields of CCBs and related structures. If a C function needs to return a cam_status, it should return an errno and pass the cam_status by reference.

I've made builds which behaved appropriately without this commit. As such this appears unnecessary, so time to abandon it.

In D30256#692969, @mhorne wrote:

This seems ready to go, but perhaps D29873 should become the child revision? I.e. cleanup first, addition second.

Part of me feels that abstracted definitions for implementation semantics is good API design, but it sounds like this is a good candidate for garbage collection.

mav caught two places I missed where xpt_bus_deregister checks the return value.

Problem with D30554 is I'm only able to test the removal. I have no PPC machine(s) to test, so I cannot say anything besides it compiles. I'm also wondering whether I should actually be removing even more from sys/dev/ofw/ofwbus.c.

Fixing goof on original version, hopefully not abusing constants to make things nicer.

In D30860#694619, @imp wrote:

Nobody is checking the return value

actually update xpt_bud_deregister too... Nobody is checking the return value so
it doesn't matter from a compat point of view, but why return anything?