Two drivers, one for bus and another for device, vs one driver

Discussion in 'Windows Vista Drivers' started by Alexander Sandler, Feb 8, 2009.

  1. I am working on a volume manager kind of device driver. I would like
    to be able to add and remove devices dynamically. I am new to windows
    drivers programming so I was wondering if you can help me to decide.

    I am considering whether to make two drivers, one dynamic bus and
    another for actual devices or to make single driver that does it all.
    I already have a bus driver more or less working and perspective of
    writing new inf file for another driver scares me. So for that matter
    single driver seems to be a good choice, yet I couldn't find any
    description of how to make it happen. It seems like things in WDF are
    sewed for two drivers. Is it possible to create a single driver that
    implements both bus and function devices? If so, how?

    Thanks.
    Alex.
     
    Alexander Sandler, Feb 8, 2009
    #1
    1. Advertisements

  2. Alexander Sandler

    Don Burn Guest

    Well you haven't given us enough data to tell what you should be doing.
    WDF is definitely not served by 2 drivers, yes it is easier than WDM to
    write a bus driver in WDF but you should only write one when you need to.

    If your driver is loke a volume manager, what is below it and what is above
    it? For example, is PartMgr aboce you and your driver is looking like the
    disk driver, or what? What do you think each driver is doing?

    Asking these questions after having written a bus driver says you have not
    thought out the architecture, in kernel programming that is a path to
    disaster.


    --
    Don Burn (MVP, Windows DDK)
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr
    Remove StopSpam to reply
     
    Don Burn, Feb 8, 2009
    #2
    1. Advertisements

  3. Don, thanks for responding.
    The function of the devices can be different from device to device.
    For a start, devices will redirect I/O requests to files. Yet I would
    like to be able to add other device types in the future - for example
    device that redirects I/O to other disk device. Each device will
    present itself as disk a device to upper layers. Hence partition
    manager will be above devices.

    I understand importance of thorough planning and design. Yet the best
    way to learn is by doing and writing code. I am not very stressed
    about time, so if it will end up bad I can redesign some modules or
    even rewrite the whole thing.

    At the moment I have a bus driver that enumerates devices according to
    configuration and does WdfChildListAddOrUpdateChildDescriptionAsPresent
    () to notify the framework that devices exist. Framework calls my
    EvtChildListCreateDevice(). This is where I am stacked. I have to
    decide whether to start working on another driver and tell WDF to load
    it (as in kmdf toaster example with dynamic enumeration) or to,
    somehow, implement everything in one driver. The later option seems to
    be more preferable because maintaining one driver is easier (not to
    mention I don't want to go through writing inf file hell again :) ).

    Alex.
     
    Alexander Sandler, Feb 9, 2009
    #3
  4. Alexander Sandler

    Don Burn Guest

    I would probably go the multiple driver route. One thing to think about is
    if you want your child devices to act like standard devices, if so you can
    save a lot of pain, by letting regular Windows drivers layer on top. For
    instance, if you choose for your volumes to have an interface that matched
    disk.sys then the partition manager and file systems would layer naturally.

    You speak of inf file hell, what problems did you have, I am wondering since
    having done inf files for 10 years, I never found them a pain. I do follow
    the strict rule of running chkinf and fixing all complaints, since warnings
    from that tool are sometimes errors, and errors are sometimes warnings.


    --
    Don Burn (MVP, Windows DDK)
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr
    Remove StopSpam to reply




    Don, thanks for responding.
    The function of the devices can be different from device to device.
    For a start, devices will redirect I/O requests to files. Yet I would
    like to be able to add other device types in the future - for example
    device that redirects I/O to other disk device. Each device will
    present itself as disk a device to upper layers. Hence partition
    manager will be above devices.

    I understand importance of thorough planning and design. Yet the best
    way to learn is by doing and writing code. I am not very stressed
    about time, so if it will end up bad I can redesign some modules or
    even rewrite the whole thing.

    At the moment I have a bus driver that enumerates devices according to
    configuration and does WdfChildListAddOrUpdateChildDescriptionAsPresent
    () to notify the framework that devices exist. Framework calls my
    EvtChildListCreateDevice(). This is where I am stacked. I have to
    decide whether to start working on another driver and tell WDF to load
    it (as in kmdf toaster example with dynamic enumeration) or to,
    somehow, implement everything in one driver. The later option seems to
    be more preferable because maintaining one driver is easier (not to
    mention I don't want to go through writing inf file hell again :) ).

    Alex.
     
    Don Burn, Feb 9, 2009
    #4
  5. I would probably go the multiple driver route.  

    I see your point. Perhaps this is indeed what I should do, especially
    considering there's an example that shows exactly how to do it (I mean
    toaster).
    I definitely will try to keep things as standard as possible.
    I had lots of Code 39 errors. Three or four kinds of them. Don't
    remember each one of them, but here's one thing that kept me busy for
    almost a week. I compiled the driver for Vista, but loaded it on XP.
    This causes Code 39 and naturally I started checking inf file for
    errors. Other issues were in the inf file itself. One thing that
    bothers me is that it's not intuitive. I don't understand what it is
    needed for. The syntax doesn't look like any other programming
    language. It mentions things that are obsolete, such as CatalogFile
    and SourceDisksFiles - I don't have any catalogs and any disks. I
    guess it is a matter of getting used to it. It shouldn't bother me
    after I will write my first ten inf files.
    I've been writing kernel applications and drivers for Linux for the
    last decade. When I started learning Windows kernel programming, some
    things came to me very naturally. For instance, paged and non-paged
    pools, irq levels, etc. These things have their counterparts in Linux.
    Just the name is different. Yet I don't know anything that even
    slightly resembles inf files in Linux. Anyway, I guess will get used
    to it :)
     
    Alexander Sandler, Feb 9, 2009
    #5
  6. Alexander Sandler

    Don Burn Guest

    Actually the rule for building drivers is simple. Use the latest WDK but
    use the oldest enviroment you wish to support. So for instance if you use
    the Windows Server 2008 WDK but want the widest support for the driver, use
    Windows 2000 for the target.

    On the INF stuff, you should have a catalogfile even though it may be empty
    at this point. The catalog is used to sign the driver to ensure it is not
    tampered with. The SourceDisksFiles is actually also useful, since it
    indicates the right things are present to the loader (for instance if you
    pointed to the INF in a directory that did not have the sys underneath it
    this could catch that).

    The INF stuff is well documented in the WDK documentation, and the general
    rule is take an examples INF and change it to your needs. Actually, IRQL
    is not the same as Linux and can cause some nasties, there were some long
    discussions on this.


    --
    Don Burn (MVP, Windows DDK)
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr
    Remove StopSpam to reply





    I see your point. Perhaps this is indeed what I should do, especially
    considering there's an example that shows exactly how to do it (I mean
    toaster).
    I definitely will try to keep things as standard as possible.
    I had lots of Code 39 errors. Three or four kinds of them. Don't
    remember each one of them, but here's one thing that kept me busy for
    almost a week. I compiled the driver for Vista, but loaded it on XP.
    This causes Code 39 and naturally I started checking inf file for
    errors. Other issues were in the inf file itself. One thing that
    bothers me is that it's not intuitive. I don't understand what it is
    needed for. The syntax doesn't look like any other programming
    language. It mentions things that are obsolete, such as CatalogFile
    and SourceDisksFiles - I don't have any catalogs and any disks. I
    guess it is a matter of getting used to it. It shouldn't bother me
    after I will write my first ten inf files.
    I've been writing kernel applications and drivers for Linux for the
    last decade. When I started learning Windows kernel programming, some
    things came to me very naturally. For instance, paged and non-paged
    pools, irq levels, etc. These things have their counterparts in Linux.
    Just the name is different. Yet I don't know anything that even
    slightly resembles inf files in Linux. Anyway, I guess will get used
    to it :)
     
    Don Burn, Feb 9, 2009
    #6
  7. almost a week. I compiled the driver for Vista, but loaded it on XP.
    Yes, this is a known no-no.
    I think that Linux supports shell/Perl/PHP scripts in the installation packages, isn't it?

    They are imperative though, while INFs are declarative.
     
    Maxim S. Shatskih, Feb 9, 2009
    #7
  8. @Maxim: I am unused to declarative languages and that's why it is so
    strange to me. I am sure it will get better though.
    Installing driver in Linux is a matter of copying it to right location
    and running another command that indexes it. Loading it is another
    command. No need for perls, shells or whatever. So it is quiet
    different.

    Eventually I found something called raw devices. I think I will stick
    to them for now. It allows me to settle with one driver instead of
    two. This may be a little irrational and may bite me in a future, but
    I fill more confident with a single driver solution for now. Raw
    devices suite well because my bus device knows everything about pdos,
    thus can provide fdo services as well.

    Anyway thanks a lot for the help and be sure I'll keep asking you
    questions :)
    Alex.
     
    Alexander Sandler, Feb 25, 2009
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.