Quoting nathan binkert <[email protected]>: >>>> For TTY-related ioctls, returning ENOTTY is the right behavior, so >>>> there's no need to print a warning. To me it's a step backward to >>>> start printing a warning for something that we're actually handling >>>> correctly. If we're not properly identifying which ioctls are >>>> TTY-related, I'd rather try and fix that than paper over it. >>> >>> The problem with the current ioctl handler is that it is very Alpha-linux >>> specific, which is based on the Tru64 syscall handler. So the way the >>> code is now, we'd either have to special case the Alpha code, or else >>> provide defines for IOCTL values that don't exist on any other Linux >>> version (mainly the weird BSD tty ioctls). So not something that's >>> impossible to fix, just something that requires some work to do properly. >> >> Yea, I think it boils down to the gap between "the right way to do it" >> and "what we have time for". > > How about you just move the existing sim/syscall_emul.hh ioctl > function to arch/alpha/linux/process.cc and make alpha use it and then > have your version used by all other ISAs. Seems like a reasonable > compromise. > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
And in the common case (common flags) you can just call one from the other. That sounds like a good solution. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
