Changeset View
Standalone View
sys/compat/linuxkpi/common/include/linux/device.h
Show First 20 Lines • Show All 553 Lines • ▼ Show 20 Lines | |||||
dev_to_node(struct device *dev) | dev_to_node(struct device *dev) | ||||
{ | { | ||||
return -1; | return -1; | ||||
} | } | ||||
char *kvasprintf(gfp_t, const char *, va_list); | char *kvasprintf(gfp_t, const char *, va_list); | ||||
char *kasprintf(gfp_t, const char *, ...); | char *kasprintf(gfp_t, const char *, ...); | ||||
/* XXX-BZ whatever they do with the _dev, I don't know yet. */ | |||||
hselasky: Why can't you just make a list in the _dev, and extend the allocation with a STAILQ entry?
Then… | |||||
bzAuthorUnsubmitted Done Inline ActionsBecause it is more than just tracking mallocs imho; I have drivers not cleaning up PCI things either and neither this nor DRM currently track it. It's an entire separate thing to implement all this and test it. If I keep doing this I'll still be talking about conflicting things with DRM in 6 months. No one says we shouldn't do this. I am trying to keep this one simple; it's been hard enough to compile it. bz: Because it is more than just tracking mallocs imho; I have drivers not cleaning up PCI things… | |||||
hselaskyUnsubmitted Done Inline ActionsI understand, but I still think we should go the extra mile and implement these functions properly. At least add a global STAILQ_HEAD() where all these allocations are listed. When we unload these are flushed. It is not much effort. (size) + sizeof(void *). Do you want me to fix it? hselasky: I understand, but I still think we should go the extra mile and implement these functions… | |||||
bzAuthorUnsubmitted Done Inline ActionsNo, as I said, the extra nile is not the extra yard. If this is done it needs to be done properly for other resources as well. I started to look into that and put a separate review up for it to make you feel more comfortable that it'll be done. Otherwise I'll just had to deal with changing everything again in a week or two. But thanks for the offer. bz: No, as I said, the extra nile is not the extra yard.
If this is done it needs to be done… | |||||
bzAuthorUnsubmitted Done Inline ActionsJust as note: I have basic "devres" support locally for some devm_ functions; currently doing the 3 pcim_ I need as well. I'll also do devres_destroy() tomorrow and that should also give @manu all what is needed for drm::drivers/gpu/drm/ttm/ttm_page_alloc_dma.c . Depending on how D27550 continues we can put things up and get them all into .. git then ;-) bz: Just as note:
I have basic "devres" support locally for some devm_ functions; currently doing… | |||||
/* XXX-BZ they seem to track allocated resources and auto-free them. */ | |||||
/* XXX-BZ TOD FIXME, we leak these resources, as noted by driver unload. */ | |||||
#define devm_kmalloc(_dev, _size, _gfp) \ | |||||
kmalloc((_size), (_gfp)) | |||||
#define devm_kzalloc(_dev, _size, _gfp) \ | |||||
devm_kmalloc((_dev), (_size), (_gfp) | __GFP_ZERO) | |||||
#define devm_kcalloc(_dev, _sizen, _size, _gfp) \ | |||||
devm_kmalloc((_dev), ((_sizen) * (_size)), (_gfp) | __GFP_ZERO) | |||||
Done Inline ActionsNot sure we want to add those functions right now. manu: Not sure we want to add those functions right now.
We need to propertly track all those malloc… | |||||
Done Inline ActionsYes, but currently this is no better or worse than the DRM implementation from what I gathered. bz: Yes, but currently this is no better or worse than the DRM implementation from what I gathered. | |||||
Done Inline ActionsThere is a lot in the drm-kmod code that needs to be in tree, the main reason that they aren't there for now is that nobody took the time to clean them and properly done them. manu: There is a lot in the drm-kmod code that needs to be in tree, the main reason that they aren't… | |||||
Done Inline ActionsThe code from the gplv2 directory is mostly not applicable to be moved into head I was told. Neither did I know about it when I initially worked on my code (which was good). I had shared my code previously so people could pick and choose and knew what was coming. The only reason I went near the DRM linuxkpi implementation is to avoid any breakage when starting to move things into HEAD putting #ifdefs around duplicate code. The only way to move forward for me is (a) to resolve conflicts with DRM, ideally in one go and bump (rather than 10) or (b) break DRM. I've been really trying hard the last weeks not to have to do (b). I can alternatively give you another big dump of my linuxkpi directory as I did in the past and let you guys sort it out.. it's just going to get bigger and won't be able to merged until the parts of this is solved. Can't we simply do the resource tracking for all the "m" functions in head a week or two after these macros went in? I'll be more than happy if I can finally unload and re-load my driver without a reboot in between as well. But I also need to track PCI resources and other things as mentioned above, not just mallocs. And I don't want to test this then against DRM while I am still resolving conflicts. But you'll get these things for free to test independently of conflicting code and can focus on the DRM parts. bz: The code from the gplv2 directory is mostly not applicable to be moved into head I was told. | |||||
Done Inline Actions
I had no idea what devres was. Sounds like "we are too lazy to properly write drivers" or "we are smart and let some common code do all the hard work for us even if it means we might hold unneeded resources for ages". Would be interesting to "profile" hit rates on these resources one day (sorry there's a researcher here in me ;-). It seems drm does use devres; at least I saw mentions of it. bz: > Not sure we want to add those functions right now.
> We need to propertly track all those… | |||||
#endif /* _LINUX_DEVICE_H_ */ | #endif /* _LINUX_DEVICE_H_ */ |
Why can't you just make a list in the _dev, and extend the allocation with a STAILQ entry?
Then there is at least some way to clean up.