Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEVBLK cleanup #288

Open
ivan-w opened this issue Mar 10, 2020 · 2 comments
Open

DEVBLK cleanup #288

ivan-w opened this issue Mar 10, 2020 · 2 comments
Assignees
Labels
Discussion Developers are invited to discuss a design change or solution to a coding problem. Enhancement This issue does not describe a problem but rather describes a suggested change or improvement.

Comments

@ivan-w
Copy link
Member

ivan-w commented Mar 10, 2020

The DEVBLK structure is completely cluttered with device dependent artifacts which are only actually of use for the device handler in charge of the emulation of the device.

This means that every time a device is created it carries around the entire package of ALL the devices known and supported.

My proposal is the DEVBLK should have a single pointer field to an opaque structure that is only relevant to the device handler using it.

This can be achieved incrementally, handler by handler, tested.

Another advantage is that creating a new device handler/emulator would no longer require making any changes to DEVBLK.

Thoughts?

@ivan-w ivan-w added Enhancement This issue does not describe a problem but rather describes a suggested change or improvement. Researching... The issue is being looked into or additional information is being gathered/located. Discussion Developers are invited to discuss a design change or solution to a coding problem. labels Mar 10, 2020
@ivan-w ivan-w self-assigned this Mar 10, 2020
@ivan-w
Copy link
Member Author

ivan-w commented Mar 10, 2020

For example:

dev->handlerdata=(void *)malloc(sizeof(struct MyDevStuff));

Then:

struct MyDevStuff *mds;
mds=(struct MyDevStuff *)dev->handlerdata;

and then use "mds" to manipulate your device emulation.

DEVBLK should only hold stuff that is generic to ALL devices, i.e. the items that allow communication between a handler and the I/O subsystem, but nothing that is specific to any specific device.

Just my €0.02

@Fish-Git
Copy link
Member

Agree 100%!

As I recall, Paul Gorlinsky tried addressing this issue a long time ago (pre-SDL Hyperion) when Jan Jaeger was still involved in Hercules and administrator of our zHercules developers group, but failed miserably at it. The specifics are a little hazy, but I seem to remember his approach was to basically convert DEVBLK (or most of it) into a union, with each different device being simply a different struct member of that union (or something like that), which may not have been the best approach to take.

Needless to say Jan didn't care for it at all and backed it out and the two got into it with each other, eventually leading to his being tossed out of the group. (At least, I think that was the cause. It was so long ago I can't remember and I'm too lazy to look it up since it's largely unimportant.)

Your approach however, seems more reasonable? Not sure.

But overall, absolutely YES, I fully 100% agree with your sentiment! This has always been a sore spot with me too! It's silly/stupid for an individual device to have to carry around all that excess baggage for other devices too! And as you explain, doing so also makes it much more difficult to develop handlers for new devices (or changes to existing handlers) since any little change that some OTHER device type happens to make to the DEVBLK structure, ends up impacting all other device types too! (which is dumb!)

The only way we're going to get out of this mess is to bite the bullet and do as you suggest: completely divorce -- perhaps gradually, device by device as you suggest -- a device's private control block fields from the "Hercules required" control block fields (e.g. the SCSW fields for example, i.e. only those fields absolutely necessary for channel.c).

So I say "Go for it!"   :)

Your idea/suggestion certainly gets my vote.

@Fish-Git Fish-Git added Ongoing Issue is long-term. Variant of IN PROGRESS: it's being worked on but maybe not at this exact moment. and removed Researching... The issue is being looked into or additional information is being gathered/located. Ongoing Issue is long-term. Variant of IN PROGRESS: it's being worked on but maybe not at this exact moment. labels Mar 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Developers are invited to discuss a design change or solution to a coding problem. Enhancement This issue does not describe a problem but rather describes a suggested change or improvement.
Projects
None yet
Development

No branches or pull requests

2 participants