As you have no doubt discovered by now, there is nothing simple about counting time

from the simple month/day versus day/month ambiguity to Einstein's simultaneity thought experiment results - which result in special and later general relativity - time is hard to observe and harder to count!

and lawyers are especially bad at doing it - except in the special case of tallying how much of it that they have spent on your behalf and therefore how much you owe.

there may be nothing that you can do against monuments of stupidity, but the absolute rule is simple - time values that get stored persistently, should be stored in UTC. and then displayed in whatever local time is appropriate.

IMO it's never a good idea to use local time to synchronize time across devices.

Imagine your device receives the time once per minute and then checks if its local time is correct.

At the beginning or end of DST, the next time information may be sent immediately before the DST status changes, so the client(s) may get the changed local time up to 1 minute delayed.

Even worse, if the client (like Windows, Linux, ...) distinguishes between UTC and local time, this may cause a step in the underlying UTC system time, and another step back shortly thereafter.

Those UTC time steps won't be visible at the first glance, but may really mess up other applications, e.g. database apps.

This is why time synchronization is usually made based on UTC (e.g. NTP) or TAI (e.g. PTP), and the client does the conversion from UTC to local time according to his preferences.

A good way to distribute local time would be to distribute the time zone rules which the client should use for a local time conversion, so the clients could be updated remotely but avoid the potential problems you get when distributing local time.

The tzdist protocol could be used to do that, but as far as I know it has not yet been implemented for this purpose.

For more details, please see also
https://kb.meinbergglobal.com/kb/time_sync/tzdist

Exactly that ... there's a binary to header utility I use [this is an example of one https://github.com/AntumDeluge/bin2header] that as a prebuild stage I use to encode the binary into a header file which is then included in the driver body

For the Cypress chips it simply parses through the header "blob" pushing the hex record contents to the chip ... for chips that want binary data it's a simple conversion from the text header "blob" to raw binary

For the more secure applications, such as medical devices or logging fobs or where there's a concern that someone with a hex editor will do some digging around there is an AES256 encryption stage in the binary to header utility prior to conversion, which means that encrypted binary is in the header file and which is decrypted by the boot firmware using a key provided by the driver using a PBKDF2 exchange of a known seed value and iteration count ...

So, the build process is ...

• Build the firmware, get the .hex images
• Encode the .hex into .h using the utility, optionally encrypting it with AES256 using a key specific to that firmware image
• Build the driver, including the .h files and have those .h portions statically linked as "blobs"

In use simply connect to the device (USB vendor commands, PCI BAR registers, etc.) and either push directly the "blob" per the device requirements or if it's encrypted query the device for a "magic register" on the device which contains the PBKDF2 seed value, and another "magic register" for the PBKDF2 iteration count, apply that to the stored PBKDF2 hash of the AES decryption key and then push the resultant key to the device and again start pushing the "blob"

One nice thing about this approach (and assuming the device can handle this, like the Cypress renumeration) is that you can first load an interrogation firmware to determine downstream devices, then the "working" firmware ... you don't need one massive firmware image for all possible permutations. Another nice thing is that you can load up a debugging firmware capable of enabling whatever you need in the field (blinky lights, board header, etc.) without exposing that debugging interface until it's needed. That really simplifies in the field debugging ...

• The device has a problem and the firmware goes into safe mode
• The driver will detect that, push the debugging firmware and trigger a device diagnostic scan as well as trigger the "blinky light" thing
• The driver collects the results of the scan and pushes that to the EventLog or similar, sometimes it will push that to a text message or email (gotta love Kernel Winsock!)
• The driver loads up a firmware that will keep the device quiesced but still able respond to usermode programs (so you don't have usermode apps crashing every time they try to use the device)

Get the email, send out a tech or whatever ... done and done!

Hi all,

We are working on a Multifunction device whose Child's Address field needs customisation . I tried editing the address field value through inf but the value gets added to the device parameters section .

This is the Child device's inf

%MCHP_PCI1xxxx-SPI.DeviceDesc% = MCHP_PCI1xxxx-SPI_Device_0, PCI\VEN_1055&DEV_A044&SUBSYS_0000000F
%MCHP_PCI1xxxx-SPI.DeviceDesc% = MCHP_PCI1xxxx-SPI_Device_1, PCI\VEN_1055&DEV_A044&SUBSYS_000000FF

[MCHP_PCI1xxxx-SPI_Device_1.NT]
CopyFiles=Drivers_Dir
AddReg = Address1.reg

[MCHP_PCI1xxxx-SPI_Device_1.NT.HW]
AddReg = MSI.reg

[Address1.reg]
HKR,,Address,0x00010001,3

[Drivers_Dir]
MCHP_PCI1xxxx-SPI.sys

[MCHP_PCI1xxxx-SPI_Device_0.NT]
CopyFiles=Drivers_Dir
AddReg = Address0.reg

[MCHP_PCI1xxxx-SPI_Device_0.NT.HW]
AddReg = MSI.reg

[Address0.reg]
HKR,,Address,0x00010001,2

Any help would be welcome

Image

KMDF is definitely the right driver model to use. When performance is a significant goal, one must take care to keep that in mind when choosing features to use through the implementation. This is true regardless of the driver model, of course… but it’s doubly so in the case of KMDF in general and KMDF USB where there are so many tempting features that can cost significant overhead.

While it certainly adds some, in general KMDF doesn’t add what I consider a LOT of overhead, over and above a similarly featured WDM driver. Much of what KMDF does are the same things you’d need to do “on your own” in your WDM driver. There’s not a lot of gratuitous nonsense in the KMDF model or Framework implementation… though the balance is generally in favor of robustness, ease of use, and debug-ability over raw speed.

Peter

I was naively thinking that filling the DMA buffer with zeros would just result in true silence when the ring buffer is empty but it's clearly not how it works,

Well, it does. The problem is that sudden drop from non-zero to zero. Unless the previous samples fade to zero, that will be seen as a high-frequency note, which comes out as a click. If the previous sample was large, the click will be loud.

maybe there was a way by which windows automatically generates a name by default

In fact, Windows will do this by default for PDOs (children of bus drivers — which is why you see useless names like PCI000021 and such on Device Objects), but not FDOs.

To answer this question with a bit more depth, if only for the archives: There are actually multiple “levels” of naming to consider. Native Device Object names (for PDOs and FDOs… they’re different), external symbolic links making the device easily accessible to user mode, and device interface GUIDs (which work out to be just another flavor of symbolic link — to the PDO — at the end of the day).

It is in fact needlessly complicated, and you can read a bit about it here (one of my favorite articles of all time).

An FDO that is both unnamed and has not created a symbolic link to its underlying PDO either directly or is creating a device interface can’t be directly targeted (even from kernel mode, without playing games like shipping the device object address around)…. but can still receive requests if something else in its Device Stack is targeted (and the request is not completed or sent to another Device Stack before it gets to the FDO in question). Again, this is how filter drivers usually work.

But…. you can’t have a driver instance without at least one Device Object instance. That is part of what you asked about, and was what I was suggesting you try, and you would see that the driver unloads immediately.

Peter

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/using-bind-or-connect-redirection

Changing the local address and port of a flow is only supported in the bind-redirect layer. This is not supported in the connect-redirect layer.

can i send IOCTL to it from userland...

No. How could you? How would you get a file handle to send the ioctl?

(or kernelland)?

No. How could you? If there's no DEVICE_OBJECT, what would you pass to IoCallDriver?