feat: expose configuration_access field in PciRoot

[AsakuraMizu]

Description

Added Deref<Target = C> and DerefMut<Target = C> implementations for PciRoot<C>.

We need this to access PCI configuration space (for example Interrupt Line) after constructing a PciRoot. See arceos-org/axdriver_crates#19.

Possible alternatives

• Add inner() and inner_mut() for PciRoot
• Implement ConfigurationAccess for PciRoot

[qwandor]

I'm not convinced that Deref is appropriate here, but I think your suggestion of inner() and inner_mut() sounds reasonable, can we do that?

[AsakuraMizu]

I'm not convinced that Deref is appropriate here, but I think your suggestion of inner() and inner_mut() sounds reasonable, can we do that?

Actually, I also think Deref is not very good. For example, the behavior of root.unsafe_clone() can cause misunderstandings, but the advantage is that it is easy to use.

Let's talk about inner()/inner_mut(). First, the name: is inner appropriate? Calling it configuration_access()/configuration_access_mut() is clearly too long. Second, this interface is somewhat difficult to use. Users need to call root.[TBD]().read_word() or root.[TBD]_mut().write_word().

---

However, I've come up with two new alternatives:

1. Instead of impl ConfigurationAccess for PciRoot, add read_word/write_word methods to PciRoot. This way, users won't accidentally call root.unsafe_clone(), but can still call other two methods as easily as Deref. The downside is the lack of extensibility.

2. (My preferred approach) Simply change the configuration_access field of PciRoot to pub.

[qwandor]

The advantage of providing access to the actual ConfigurationAccess implementation (rather than adding methods to PciRoot or implementing ConfigurationAccess for it) is that the specific implementation might have methods which are not part of the trait but which someone might want to call, such as the is_pkvm() method on HypCam. I'm fine with either inner or configuration_access as the name of the method, I don't think the length of the name is a big issue as long as it's clear.

Making the field public is also fine I guess.

[qwandor]

Actually yeah, I think making the field public is the best solution. It provides exactly the same capabilities as adding the methods, and is simpler.